Kernel bug triage

Kevin Fenzi kevin at scrye.com
Mon Apr 19 19:30:36 UTC 2010


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? :) 

- Should we ask folks for more info and close bugs after some
  predefined time? How long should that be?

- Should feature requests be closed and reporter asked to file upstream?

- 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?

- 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


More information about the kernel mailing list