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. Gavin _______________________________________________ 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"
