On Mon, Apr 19, 2010 at 01:30:36PM -0600, Kevin Fenzi wrote:
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
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
Depends on the feature request.
- Should bugs that contain patches get a PATCH subject line or be
asked to report upstream?
- Is there a list of commands that would be helpful to run on any
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
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
this option' type requests. Would they be good to mark ?
Probably. Those are usually easy to answer.
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. ;)