In message: <alpine.lnx.2.00.1009231841500.23...@ury.york.ac.uk> Gavin Atkinson <ga...@freebsd.org> writes: : On Thu, 23 Sep 2010, Ken Smith wrote: : > The issues talked about so far all contribute to the reason for that. : > But one of the more basic gut reactions to it all is that the users : > want to be interested in helping with the debugging (even if just : > providing the requested info) for any sort of crash information : > to be useful. And at the point we shift something from -current : > to -stable the percentage of people actively interested in participating : > in that sort of stuff flip. The bulk of people using -current : > know it's risky and they do it out of some interest in debugging : > stuff. The *bulk* of people using -stable are less interested or : > flat out not interested. And have no clue what crash dumps are, : > may be challenged to notice partition-getting-full issues, etc. : : I'm not sure I buy this argument, I'm afraid. Part of the advantage of : having all this done automatically on the as-shipped release media is that : end users don't have to be interested in debugging - crashinfo(8) does : most of the work for them. There's no easy way to actually determine : figures, but even if say only 10-15% of crashes can be diagnosed and : corrected just from the output of crashinfo(8) then that's a huge win for : the project as a whole. I'm guessing 10-15% is not unrealistic. : : I appreciate the issue about filling partitions is a valid one. Would a : possible compromise be that on release media, crashinfo(8) or similar will : default to only keeping the most recent coredump or similar? Given /var : now defaults to 4GB, Defaulting to keeping a single core is probably : acceptable.
Furthermore, if we aren't interested in crash dumps by default, why do we install the huge .symbols files? Warner _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"