On Mon, Apr 19, 2010 at 01:30:36PM -0600, Kevin Fenzi wrote: > Greetings. > > I happened to see the other week that there are currently around 1600 > open kernel bugs in bugzilla against currently supported Fedora > releases. :( The large majority of them are in NEW, and it's unclear > how many are at all useful to us. > > I'd like to revisit the idea of getting a team of bugzappers working on > triaging the kernel bugs so we do know more about whats got useful info > and what does not and let kernel maintainers be able to more clearly > see what could be worked on. > > So, the first question: Would this effort be worthwhile to kernel > maintainers? I'd say "yes", if the triage team is competent enough. I guess that more or less translates to "perhaps". > If 'yes', or 'perhaps', I have a bunch more questions about how you > folks would like to handle things: > > - Should bugs showing the user has a tainted kernel be simply closed? > Or should reporter be asked to duplicate without the tainting module? > Or both? :) Must duplicate without taint. > - Should we ask folks for more info and close bugs after some > predefined time? How long should that be? I'd leave them in NEEDINFO for one full release cycle. If there's still no reply, then close them. > - Should feature requests be closed and reporter asked to file upstream? Depends on the feature request. > - Should bugs that contain patches get a PATCH subject line or be just > asked to report upstream? Possibly both. > - Is there a list of commands that would be helpful to run on any new > reported issue? uname/lsmod/dmesg? Anything else? Would smolt > profiles be of help? I usually find dmesg right after a fresh boot and dmesg immediately after the problem surfaces (if its not during boot) to be essential, and the smolt profile is probably helpful to figure out exactly what hardware we're dealing with. Booting with 'quiet' replaced by 'debug' on the kernel boot line, and giving that dmesg output, is occasionally also helpful, as is loading troublesome modules with any extra debug options they may have. > - Ideally I would like to sort bugs into large buckets based on > subsystem, and then put keywords or something on them so subsystem > maintainers could easily look at the bugs in their area. What would > be a list of such subsystems that would be useful? Looks like this is being discussed on irc a bit right now... > - Would it be helpfull to add a keyword or whiteboard on what kernel > version it was reported with? Then a search could find all bugs with > that particular version (of course it would need to change if > reporter updated, etc). I'd say yes. > - There seem to be a fair number of 'enable this option' or 'disable > this option' type requests. Would they be good to mark ? Probably. Those are usually easy to answer. > I've started a draft page at: > https://fedoraproject.org/wiki/KernelTriage > > I'd like to flesh it out more and look at adding some canned responses > there and then see how much interest there is to do this. > Comments/edits/shouting welcome. ;) Good start. -- Jarod Wilson jarod@xxxxxxxxxx _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
