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.
Team of bugzappers sounds ok, but I'd rather leverage the community
at the lowest/earliest level, by giving the report at least the opportunity
to say, for example, "this looks like a filesystem/ext4/xfs/network/scsi/whatever
And then I'd see it, for the relevant buckets.
Today I don't even look, because it's just a giant stew.
So if we can't do better on the filing end, then maybe a team of bugzappers
is warranted ... but can't we do better on the filing end?
If I had a filesystem-related bucket or buckets to look at for fedora kernel
bugs, I'd do it. Esp. if it sent me email.
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? :)
- 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:
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