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
Hi,
2010/4/19 Kevin Fenzi kevin@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=Do...
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Mon, 2010-04-19 at 13:30 -0600, 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.
[snip various proposals]
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. ;)
FWIW I wrote a triaging script to help me deal with incoming "python" bugs, especially those filed by ABRT - you feed it a bug ID and it suggests a course of action to take. It might be possible to use it for use on incoming "kernel" bugs, or at least as the start of something analagous; feel free to hack it up as need be.
The script is here: http://fedorapeople.org/gitweb?p=dmalcolm/public_git/triage.git;a=summary
(Note that the GTK UI doesn't work yet)
Hope this is helpful Dave
On Mon, Apr 19, 2010 at 01:30:36PM -0600, 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.
So, the first question: Would this effort be worthwhile to kernel maintainers?
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 upstream?
Depends on the feature request.
- Should bugs that contain patches get a PATCH subject line or be just asked to report upstream?
Possibly both.
- 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?
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 kernel 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 'disable this option' type requests. Would they be good to mark ?
Probably. Those are usually easy to answer.
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. ;)
Good start.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Eric Sandeen wrote:
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"
Er, to be clearer, I mean in a bugzilla-searchable & classifiable way. Not just comments.
-Eric
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
On Mon, 19 Apr 2010 15:14:25 -0500 Eric Sandeen sandeen@redhat.com wrote:
Er, to be clearer, I mean in a bugzilla-searchable & classifiable way. Not just comments.
Right, that could be 'keywords' or 'whiteboard' ?
kevin
On Mon, 19 Apr 2010 15:11:30 -0500 Eric Sandeen sandeen@redhat.com wrote:
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?
Well, I asked around about that, but not sure how easy/possible it is to do with our current setup. Basically bugzilla gets populated from pkgdb, which has a list of packages, owners, cc people, etc.
It doesn't have a way to say: kernel is this, and has subsystem X, Y, Z
Of course we might be able to change the setup, but thats not going to be easy/short term. :( I also wish there was a way to setup a template per component, so we could ask the reporters for all the standard things we want and point them at the kernelcommon issues page, etc.
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.
How about if a group of bugzappers added you to CC and add a 'filesystem' keyword on the bug so you could search for all those?
We could also try and train reporters to add these keywords when they know?
I exchanged some emails with Chris Brown and I think I am going to look at just updating the https://fedoraproject.org/wiki/KernelBugTriage page. That page has a list of bug assignments that we could update and use for this.
-Eric
kevin
Kevin Fenzi wrote:
On Mon, 19 Apr 2010 15:11:30 -0500 Eric Sandeen sandeen@redhat.com wrote:
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?
Well, I asked around about that, but not sure how easy/possible it is to do with our current setup. Basically bugzilla gets populated from pkgdb, which has a list of packages, owners, cc people, etc.
It doesn't have a way to say: kernel is this, and has subsystem X, Y, Z
Yep, that's the answer I'd heard before too, unfortunately. It's a pity that the tools seem to be this inflexible.
the kernel.org bugzilla is much better at this. :(
Of course we might be able to change the setup, but thats not going to be easy/short term. :( I also wish there was a way to setup a template per component, so we could ask the reporters for all the standard things we want and point them at the kernelcommon issues page, etc.
That'd be nice too.
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.
How about if a group of bugzappers added you to CC and add a 'filesystem' keyword on the bug so you could search for all those?
We could also try and train reporters to add these keywords when they know?
I exchanged some emails with Chris Brown and I think I am going to look at just updating the https://fedoraproject.org/wiki/KernelBugTriage page. That page has a list of bug assignments that we could update and use for this.
I think anything that lets the initial reporter take a stab at putting things in the right bucket would help; ideally, it'd be a mechanism that sends me email, but if it at least is queryable that'd help...
Thanks, -Eric
-Eric
kevin
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Sun, 2010-04-25 at 21:58 -0500, Eric Sandeen wrote:
Kevin Fenzi wrote:
On Mon, 19 Apr 2010 15:11:30 -0500 Eric Sandeen sandeen@redhat.com wrote:
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?
Well, I asked around about that, but not sure how easy/possible it is to do with our current setup. Basically bugzilla gets populated from pkgdb, which has a list of packages, owners, cc people, etc.
It doesn't have a way to say: kernel is this, and has subsystem X, Y, Z
Yep, that's the answer I'd heard before too, unfortunately. It's a pity that the tools seem to be this inflexible.
the kernel.org bugzilla is much better at this. :(
btw ... kernel.org bugzilla just have the subsystems as independent components in Bugzilla. I do think, it's not a problem to do the same at bugzilla.redhat.com. It would be a clear benefit for the triagers, they will just move bugs to the proper component and owners-mail-list of the component, so that group of people, in charge for the subsystem will be automatically notified.
does it make sense? I will speak to rh-bugzilla crew.
// and we need to think of the subsystems, we want to have. It's // better to have them generalized and not too much.
Of course we might be able to change the setup, but thats not going to be easy/short term. :( I also wish there was a way to setup a template per component, so we could ask the reporters for all the standard things we want and point them at the kernelcommon issues page, etc.
That'd be nice too.
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.
How about if a group of bugzappers added you to CC and add a 'filesystem' keyword on the bug so you could search for all those?
We could also try and train reporters to add these keywords when they know?
I exchanged some emails with Chris Brown and I think I am going to look at just updating the https://fedoraproject.org/wiki/KernelBugTriage page. That page has a list of bug assignments that we could update and use for this.
I think anything that lets the initial reporter take a stab at putting things in the right bucket would help; ideally, it'd be a mechanism that sends me email, but if it at least is queryable that'd help...
Thanks, -Eric
-Eric
kevin
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Mon, 26 Apr 2010 08:04:57 +0200 Anton Arapov anton@redhat.com wrote:
btw ... kernel.org bugzilla just have the subsystems as independent components in Bugzilla. I do think, it's not a problem to do the same at bugzilla.redhat.com. It would be a clear benefit for the triagers, they will just move bugs to the proper component and owners-mail-list of the component, so that group of people, in charge for the subsystem will be automatically notified.
Yeah, I agree, but currently it's not very easy to do that...
does it make sense? I will speak to rh-bugzilla crew.
Well, the Fedora product in bugzilla.redhat.com is populated from fedora's pkgdb, so there is not currently a way to get it to divide a single package to a bunch of components.
I'm adding Toshio here to comment (or not as he sees fit) about the pkgdb side of things.
// and we need to think of the subsystems, we want to have. It's // better to have them generalized and not too much.
yes, the division there needs to be pondered on.
As a first cut, I would say split out anything where there is a person/team that is willing to work on that area, then see whats left.
kevin
On Sun, Apr 25, 2010 at 09:58:12PM -0500, Eric Sandeen wrote:
Well, I asked around about that, but not sure how easy/possible it is to do with our current setup. Basically bugzilla gets populated from pkgdb, which has a list of packages, owners, cc people, etc.
It doesn't have a way to say: kernel is this, and has subsystem X, Y, Z
Yep, that's the answer I'd heard before too, unfortunately. It's a pity that the tools seem to be this inflexible.
the kernel.org bugzilla is much better at this. :(
There's no /particular/ reason we couldn't use the kernel.org bugzilla for Fedora if it would improve things...
--Kyle
On Mon, Apr 26, 2010 at 11:21:02AM -0400, Kyle McMartin wrote:
On Sun, Apr 25, 2010 at 09:58:12PM -0500, Eric Sandeen wrote:
Well, I asked around about that, but not sure how easy/possible it is to do with our current setup. Basically bugzilla gets populated from pkgdb, which has a list of packages, owners, cc people, etc.
It doesn't have a way to say: kernel is this, and has subsystem X, Y, Z
Yep, that's the answer I'd heard before too, unfortunately. It's a pity that the tools seem to be this inflexible.
the kernel.org bugzilla is much better at this. :(
There's no /particular/ reason we couldn't use the kernel.org bugzilla for Fedora if it would improve things...
the problem with using the kernel.org bz for Fedora bugs is that if they report a bug which turns out not to be a kernel bug, we can't reassign it to the right package, they need to file a new bug back at rhbz.
It's sad that after all these years the only bz interoperability solution that's appeared is "use launchpad", which isn't a solution at all.
Dave
On Mon, 26 Apr 2010 12:14:43 -0400 Dave Jones davej@redhat.com wrote:
On Mon, Apr 26, 2010 at 11:21:02AM -0400, Kyle McMartin wrote:
On Sun, Apr 25, 2010 at 09:58:12PM -0500, Eric Sandeen wrote:
Well, I asked around about that, but not sure how easy/possible it is to do with our current setup. Basically bugzilla gets populated from pkgdb, which has a list of packages, owners, cc people, etc.
It doesn't have a way to say: kernel is this, and has subsystem X, Y, Z
Yep, that's the answer I'd heard before too, unfortunately. It's a pity that the tools seem to be this inflexible.
the kernel.org bugzilla is much better at this. :(
There's no /particular/ reason we couldn't use the kernel.org bugzilla for Fedora if it would improve things...
the problem with using the kernel.org bz for Fedora bugs is that if they report a bug which turns out not to be a kernel bug, we can't reassign it to the right package, they need to file a new bug back at rhbz.
Also, many people won't know to do that, so they will report bugs against something else in fedora (if we remove the kernel component) or keep filing them in the fedora bugzilla (if we leave the kernel component).
It's sad that after all these years the only bz interoperability solution that's appeared is "use launchpad", which isn't a solution at all.
Yes indeed. ;(
kevin
kernel@lists.fedoraproject.org