2010/4/19 Kevin Fenzi <kevin(a)scrye.com>:
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
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
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:
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. ;)
kernel mailing list