Hi, 2010/4/19 Kevin Fenzi <kevin@xxxxxxxxx>: > 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? > > 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? :) Second option. Oopses in tainted kernels aren't useful for kernel developers. > > - Should we ask folks for more info and close bugs after some > predefined time? How long should that be? I reported a two kernel bugs and at least one is still present in .32 (it rather a warning, but still) - reported against 2.6.29. > > - Should feature requests be closed and reporter asked to file upstream? Upstream fixes only upstream bugs AFAIK. I'm too lazy to build my own kernel ;) > > - Should bugs that contain patches get a PATCH subject line or be just > asked to report upstream? > > - 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? There was a doc about submiting bug reports http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=Documentation;h=c5d59ee59f70869914cf0e775b63a9bc7fca6c79;hb=HEAD There was also something called oops reporting tool that did the trick. > > - 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? > > - 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). > > - There seem to be a fair number of 'enable this option' or 'disable > this option' type requests. Would they be good to mark ? > > 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. ;) > > kevin > > _______________________________________________ > kernel mailing list > kernel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/kernel > _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
