Kernel bug triage
Michał Piotrowski
mkkp4x4 at gmail.com
Mon Apr 19 19:42:17 UTC 2010
Hi,
2010/4/19 Kevin Fenzi <kevin at scrye.com>:
> 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? :)
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
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=Documentation;h=c5d59ee59f70869914cf0e775b63a9bc7fca6c79;hb=HEAD
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:
> 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