Kernel bug triage

Eric Sandeen sandeen at redhat.com
Mon Apr 19 20:11:30 UTC 2010


Kevin Fenzi wrote:
> 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. 

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 bug"

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.

-Eric

> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> kernel mailing list
> kernel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/kernel



More information about the kernel mailing list