Dedicated kernel bug database
Following on from yesterday's discussion about there not being much interaction between the kernel Bugzilla and the developers, I began wondering whether Bugzilla might be a bit too generic to be suited to kernel development, and that maybe a system written from the ground up for reporting kernel bugs would be better?
I.E. I am prepared to write it myself, if people think it's worthwhile.
For example, we get a lot of posts on LKML like this:
"Hi, foobar doesn't work in 2.4.19"
Now, does that mean:
* The bug first appeared in 2.4.19, and is still in 2.4.20
* The bug reporter hasn't tested 2.4.20
* The bug reporter can't test 2.4.20 because something else is broken
* The bug actually first appeared in 2.4.10, but it didn't irritate them enough to complain until now.
A bug database designed from scratch could allow such information to be indexed in a way that could be processed and searched usefully. A list of tick-boxes for worked/didn't work/didn't test/couldn't test for several kernel versions could be presented.
Also, we could have a non-web interface, (telnet or gopher to the bug DB, or control it by E-Mail).
It could warn the user if they attach an un-decoded oops that their bug report isn't as useful as it could be, and if they mention a distribution kernel version, that it's not a tree that the developers will necessarily be familiar with.
I'm not criticising the fact that we've got Bugzilla up and running, but just pointing out that we could do better, (and I'm prepared to put in the time and effort). I just need ideas, really.
John.
I would just like to second what somebody said about bugzilla yesterday, that it is hard to search for bugs that have already been entered. Just something to think about.
--Brian Jackson
Quoted 44 lines · John Bradford
Following on from yesterday's discussion about there not being much interaction between the kernel Bugzilla and the developers, I began wondering whether Bugzilla might be a bit too generic to be suited to kernel development, and that maybe a system written from the ground up for reporting kernel bugs would be better?
I.E. I am prepared to write it myself, if people think it's worthwhile.
For example, we get a lot of posts on LKML like this:
"Hi, foobar doesn't work in 2.4.19"
Now, does that mean:
* The bug first appeared in 2.4.19, and is still in 2.4.20
* The bug reporter hasn't tested 2.4.20
* The bug reporter can't test 2.4.20 because something else is broken
* The bug actually first appeared in 2.4.10, but it didn't irritate them enough to complain until now.A bug database designed from scratch could allow such information to be indexed in a way that could be processed and searched usefully. A list of tick-boxes for worked/didn't work/didn't test/couldn't test for several kernel versions could be presented.
Also, we could have a non-web interface, (telnet or gopher to the bug DB, or control it by E-Mail).
It could warn the user if they attach an un-decoded oops that their bug report isn't as useful as it could be, and if they mention a distribution kernel version, that it's not a tree that the developers will necessarily be familiar with.
I'm not criticising the fact that we've got Bugzilla up and running, but just pointing out that we could do better, (and I'm prepared to put in the time and effort). I just need ideas, really.
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines
I would just like to second what somebody said about bugzilla yesterday, that it is hard to search for bugs that have already been entered. Just
something to think about. --Brian Jackson
Give me an example ... what are you trying to search for?
M.
Quoted 5 lines · John Bradford
Following on from yesterday's discussion about there not being much interaction between the kernel Bugzilla and the developers, I began wondering whether Bugzilla might be a bit too generic to be suited to kernel development, and that maybe a system written from the ground up for reporting kernel bugs would be better?
Can you perhaps improve bugzilla instead of starting over? (I have not looked at bugzilla code... I'm just hoping we can build from where we are instead of starting over.)
Quoted 7 lines
I.E. I am prepared to write it myself, if people think it's worthwhile.
For example, we get a lot of posts on LKML like this:
"Hi, foobar doesn't work in 2.4.19"
Quoted 7 lines
Now, does that mean:
* The bug first appeared in 2.4.19, and is still in 2.4.20
* The bug reporter hasn't tested 2.4.20
* The bug reporter can't test 2.4.20 because something else is broken
* The bug actually first appeared in 2.4.10, but it didn't irritate them enough to complain until now.
This case is not specific to the kernel:
"feature X doesn't work in program Y version Z"
it may appear in Z-3 through Z+1, but fixed in Z+2, etc. So I hope it is something that could be done in/added to bugzilla.
Quoted 7 lines
A bug database designed from scratch could allow such information to be indexed in a way that could be processed and searched usefully. A list of tick-boxes for worked/didn't work/didn't test/couldn't test for several kernel versions could be presented.
Also, we could have a non-web interface, (telnet or gopher to the bug DB, or control it by E-Mail).
Can you interface with bugzilla's database backend maybe? It seems like refactoring bugzilla might be better?
Quoted 4 lines
It could warn the user if they attach an un-decoded oops that their bug report isn't as useful as it could be, and if they mention a distribution kernel version, that it's not a tree that the developers will necessarily be familiar with.
Perhaps a more generalized hook into bugzilla for 'validating' a bug report, then code specific validators for kernel work?
Quoted 3 lines
I'm not criticising the fact that we've got Bugzilla up and running, but just pointing out that we could do better, (and I'm prepared to put in the time and effort). I just need ideas, really.
I certainly do not want to stand in your way! I just hope you can stand on the shoulders of giants.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
Quoted 4 lines · Eli Carter
Quoted 2 lines
Also, we could have a non-web interface, (telnet or gopher to the bug DB, or control it by E-Mail).
Can you interface with bugzilla's database backend maybe? It seems like refactoring bugzilla might be better?
It's an annoyance to me that the current bugzilla we use can only do 1 way email. Ie, I receive email when things change, but I can't reply to that mail and have my comments auto-added.
Other bugzillas can do this, so I think either some switch needs to be enabled, or theres some extension not present.
(I'm a complete bugzilla weenie, and no nothing about how its set up).
Quoted 6 lines
Quoted 4 lines
It could warn the user if they attach an un-decoded oops that their bug report isn't as useful as it could be, and if they mention a distribution kernel version, that it's not a tree that the developers will necessarily be familiar with
Perhaps a more generalized hook into bugzilla for 'validating' a bug report, then code specific validators for kernel work?
Its a nice idea, but I think it's a lot of effort to get it right, when a human can look at the dump, realise its not decoded, and send a request back in hardly any time at all.
I also don't trust things like this where if something goes wrong, we could lose the bug report. People are also more likely to ping-pong ,argue or "how do I..." with a human than they are with an automated robot.
Dave
Signature · 1 line
| Dave Jones. http://www.codemonkey.org.uk
Quoted 10 lines
Quoted 6 lines
Quoted 4 lines
It could warn the user if they attach an un-decoded oops that their bug report isn't as useful as it could be, and if they mention a distribution kernel version, that it's not a tree that the developers will necessarily be familiar with
Perhaps a more generalized hook into bugzilla for 'validating' a bug report, then code specific validators for kernel work?
Its a nice idea, but I think it's a lot of effort to get it right, when a human can look at the dump, realise its not decoded, and send a request back in hardly any time at all.
Somebody still has to answer it - loads of mails to LKML go unanswered because people are spending their time coding instead of reading the list, (which is good).
Quoted 2 lines
I also don't trust things like this where if something goes wrong, we could lose the bug report.
How? I don't see as that is more likely than with Bugzilla. Anyway, loads of LKML posts get ignored, and nobody seems to worry about it :-).
Quoted 2 lines
People are also more likely to ping-pong ,argue or "how do I..." with a human than they are with an automated robot.
The idea is that the bug database does a sanity check on their bug report. It still gets entered in to the database, but it would return something like:
"
Hi,
You submitted a bug to the bug database. Please note the following:
* You mentioned kernel version foobar. This appears to be a vendor kernel, not an official kernel tree. Your distribution maintainers might be more appropriate people to contact
* You included an undecoded oops - this is probably useless. Please read the FAQ.
Thanks for using the bug database. Your bug has been assigned to [whoever].
"
I don't see any way of making Bugzilla do all the things I described originally, specifically the advanced tracking of versions tested. That could help to find duplicates, which is a big problem when you have 1000+ bugs.
John.
Quoted 3 lines · John Bradford
Quoted 2 lines
I also don't trust things like this where if something goes wrong, we could lose the bug report.
How? I don't see as that is more likely than with Bugzilla.
user submits bug report
robot rejects it
user reads rejection, gets confused, gives up.
Quoted 1 line
Anyway, loads of LKML posts get ignored, and nobody seems to worry about it :-).
Point to one important posting thats been ignored in recent times. More likely they weren't ignored, it was just deemed irrelevant, unimportant, or lacked information detailing how important the problem was.
Besides, this is one area where bugzilla is helping. If I ignored/missed an agp related bug report on linux kernel, and the same user also filed it in bugzilla, I'll get pestered about it automatically later.
Quoted 2 lines
I don't see any way of making Bugzilla do all the things I described originally, specifically the advanced tracking of versions tested.
I still think you're solving a non-problem. Of the 180 or so bugs so far, there has been _1_ vendor kernel report. 1 2.4 report. and 1 (maybe 2) undecoded oopses (which were subsequently decoded less than 24hrs later.
Quoted 2 lines
That could help to find duplicates, which is a big problem when you have 1000+ bugs.
In an ideal world, we'd never have that many open bugs 8-) Realistically, I check bugzilla a few times a day, I notice when something new has been added. Near the end of each week I[*] go through every remaining open bug looking to see if there's something additional that can be added / pinging old reporters / closing dead bugs. Dupes usually stand out doing this. How exactly do you plan to automate dupe detection ? You can't even do things like comparing oops dumps, as they may have been triggered in different ways,.
Dave
[*] and hopefully, I'm not the only one who does this.
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
I also don't trust things like this where if something goes wrong, we could lose the bug report.
How? I don't see as that is more likely than with Bugzilla.
user submits bug report
robot rejects it
It's not coded to reject stuff. Just parse it and point out obvious mistakes.
Quoted 1 line
user reads rejection, gets confused, gives up.
I do see what you mean, but that's not how I see it working:
user submits bug report
[it gets stored]
robot generates messages similar to compiler *warnings*.
Quoted 3 lines
Quoted 1 line
Anyway, loads of LKML posts get ignored, and nobody seems to worry about it :-).
Point to one important posting thats been ignored in recent times.
What about that data corruption bug that was pointed out around 2.4.18, and brought up again, when it was discovered that the patch wasn't applied. That is a case of a bug report getting lost. Not exactly what I meant, though, but it's relevant.
Quoted 3 lines
More likely they weren't ignored, it was just deemed irrelevant, unimportant, or lacked information detailing how important the problem was.
Well, that's what the automated warnings would protect against - at least the user would get a response, telling them how to submit a more useful response.
Quoted 4 lines
Besides, this is one area where bugzilla is helping. If I ignored/missed an agp related bug report on linux kernel, and the same user also filed it in bugzilla, I'll get pestered about it automatically later.
Agreed.
Quoted 7 lines
Quoted 2 lines
I don't see any way of making Bugzilla do all the things I described originally, specifically the advanced tracking of versions tested.
I still think you're solving a non-problem. Of the 180 or so bugs so far, there has been _1_ vendor kernel report. 1 2.4 report. and 1 (maybe 2) undecoded oopses (which were subsequently decoded less than 24hrs later.
Well, if we never get above that rate of bugs being entered in to the database, then we might as well not have it, and go back to having everything on LKML.
Quoted 4 lines
Quoted 2 lines
That could help to find duplicates, which is a big problem when you have 1000+ bugs.
In an ideal world, we'd never have that many open bugs 8-)
Good point :-)
Quoted 8 lines
Realistically, I check bugzilla a few times a day, I notice when something new has been added. Near the end of each week I[*] go through every remaining open bug looking to see if there's something additional that can be added / pinging old reporters / closing dead bugs. Dupes usually stand out doing this. How exactly do you plan to automate dupe detection ? You can't even do things like comparing oops dumps, as they may have been triggered in different ways,.
I mean make it easier for people to identify dupes.
I've got loads of ideas about how we could build a better bug database
- for example, we have categories at the moment in Bugzilla. Why? We already have a MAINTAINERS file, so say somebody looks up the relevant maintainer in that list, finds them, then goes to enter a bug in Bugzilla. Now they have to assign it to a category, and different people may well assign the same bug to different categories - immediately making duplicate detection more difficult.
If the number of bugs is always going to stay low, then my idea is probably a waste of time, but I think that we are eventually going to have loads of bug reports. We _want_ more bug reports, especially in the development tree. Few enough people are testing it as it is!
John.
Quoted 1 line
I've got loads of ideas about how we could build a better bug database
Go ahead, knock yourself out. Come back when you're done.
Quoted 6 lines
- for example, we have categories at the moment in Bugzilla. Why? We already have a
MAINTAINERSfile, so say somebody looks up the relevant maintainer in that list, finds them, then goes to enter a bug in Bugzilla. Now they have to assign it to a category, and different people may well assign the same bug to different categories - immediately making duplicate detection more difficult.
Have you actually looked at the maintainers file? It's a twisted mess of outdated information, in no well formated order. The category list in Bugzilla was an attempt to bring some sanity to the structure, though I won't claim it's perfect. We really need a 3-level tree, but that's a fair amount of work to code.
M.
[CC list trimmed]
Quoted 3 lines
Quoted 1 line
I've got loads of ideas about how we could build a better bug database
Go ahead, knock yourself out. Come back when you're done.
Not sure what you mean. I do intend to start coding a new bug database system today, and I'll announce it on the list when it's ready. If nobody likes it, I wasted my time.
Quoted 8 lines
Quoted 6 lines
- for example, we have categories at the moment in Bugzilla. Why? We already have a
MAINTAINERSfile, so say somebody looks up the relevant maintainer in that list, finds them, then goes to enter a bug in Bugzilla. Now they have to assign it to a category, and different people may well assign the same bug to different categories - immediately making duplicate detection more difficult.Have you actually looked at the maintainers file?
Yes.
Quoted 1 line
It's a twisted mess of outdated information,
Then it should be updated, that is nothing to do with Bugzilla.
Quoted 1 line
in no well formated order.
Looks easy enough to parse with regular expressions to me.
Quoted 2 lines
The category list in Bugzilla was an attempt to bring some sanity to the structure,
By adding an extra layer of abstraction. I don't agree that that helps.
Quoted 2 lines
though I won't claim it's perfect. We really need a 3-level tree, but that's a fair amount of work to code.
I disagree, (that we need a 3-level tree).
John.
Quoted 5 lines · John Bradford
Quoted 2 lines
Quoted 1 line
I've got loads of ideas about how we could build a better bug database
Go ahead, knock yourself out. Come back when you're done.
Not sure what you mean. I do intend to start coding a new bug database system today, and I'll announce it on the list when it's ready. If nobody likes it, I wasted my time.
So explain exactly what you intend to do. Maybe you're right, and there are serious shortfallings. Right now all I see is whining about "Bugzilla sucks, I could write a better one" with no actual facts about why it sucks.
Dave
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 3 lines
Not sure what you mean. I do intend to start coding a new bug database system today, and I'll announce it on the list when it's ready. If nobody likes it, I wasted my time.
That's basically what I meant ... try coding it and see. My wierd Anglicisms in forms of speech ...
Quoted 7 lines
Quoted 1 line
Have you actually looked at the maintainers file?
Yes.
Quoted 1 line
It's a twisted mess of outdated information,
Then it should be updated, that is nothing to do with Bugzilla.
Right. But I wasn't interested in doing that. And code maintainers won't necessarily want to be bug database maintainers (though I did get a suprising number of people to sign up).
Quoted 5 lines
Quoted 2 lines
The category list in Bugzilla was an attempt to bring some sanity to the structure,
By adding an extra layer of abstraction. I don't agree that that helps.
Well, I guess we differ on that then.
Quoted 4 lines
Quoted 2 lines
though I won't claim it's perfect. We really need a 3-level tree, but that's a fair amount of work to code.
I disagree, (that we need a 3-level tree).
We don't *need* one, it'd be nice though.
M.
[cc list trimmed]
On Thu, 19 Dec 2002, Dave Jones wrote:
| On Thu, Dec 19, 2002 at 07:52:29PM +0000, John Bradford wrote: | > > I also don't trust things like this where if something goes wrong, | > > we could lose the bug report. | > How? I don't see as that is more likely than with Bugzilla. | | user submits bug report | robot rejects it | user reads rejection, gets confused, gives up. | | > Anyway, loads of LKML posts get ignored, and nobody seems to worry about it :-). | | Point to one important posting thats been ignored in recent times. | More likely they weren't ignored, it was just deemed irrelevant, | unimportant, or lacked information detailing how important the problem | was.
It can be difficult to tell the difference.
| Besides, this is one area where bugzilla is helping. | If I ignored/missed an agp related bug report on linux kernel, | and the same user also filed it in bugzilla, I'll get pestered | about it automatically later. | | > I don't see any way of making Bugzilla do all the things I described | > originally, specifically the advanced tracking of versions tested. | | I still think you're solving a non-problem. Of the 180 or so bugs so | far, there has been _1_ vendor kernel report. 1 2.4 report. and | 1 (maybe 2) undecoded oopses (which were subsequently decoded less | than 24hrs later. | | > That could help to find duplicates, which is a big problem when you | > have 1000+ bugs. | | In an ideal world, we'd never have that many open bugs 8-) | Realistically, I check bugzilla a few times a day, I notice | when something new has been added. Near the end of each week | I[*] go through every remaining open bug looking to see if there's | something additional that can be added / pinging old reporters / | closing dead bugs. Dupes usually stand out doing this. | How exactly do you plan to automate dupe detection ? | You can't even do things like comparing oops dumps, as they | may have been triggered in different ways,. | | Dave | | [*] and hopefully, I'm not the only one who does this.
Yes, I go thru them fairly often also, looking for patches or to apply some patches to close some if possible.
I hope we aren't the only ones...
Signature · 1 line
~Randy
Quoted 1 line · Dave Jones
On Thu, Dec 19, 2002 at 11:48:16AM -0600, Eli Carter wrote:
[snip]
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
It could warn the user if they attach an un-decoded oops that their bug report isn't as useful as it could be, and if they mention a distribution kernel version, that it's not a tree that the developers will necessarily be familiar with
Perhaps a more generalized hook into bugzilla for 'validating' a bug report, then code specific validators for kernel work?
Quoted 6 lines
Its a nice idea, but I think it's a lot of effort to get it right, when a human can look at the dump, realise its not decoded, and send a request back in hardly any time at all.
I also don't trust things like this where if something goes wrong, we could lose the bug report. People are also more likely to ping-pong ,argue or "how do I..." with a human than they are with an automated robot.
Either way, it isn't kernel specific.... which is what I was trying to address. If it is valuable (which as you demonstrate is debatable,) then it is valuable in bugzilla baseline, not just kernel-bugzilla.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
[CC list trimmed]
Quoted 14 lines
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
It could warn the user if they attach an un-decoded oops that their bug report isn't as useful as it could be, and if they mention a distribution kernel version, that it's not a tree that the developers will necessarily be familiar with
Perhaps a more generalized hook into bugzilla for 'validating' a bug report, then code specific validators for kernel work?
Quoted 6 lines
Its a nice idea, but I think it's a lot of effort to get it right, when a human can look at the dump, realise its not decoded, and send a request back in hardly any time at all.
I also don't trust things like this where if something goes wrong, we could lose the bug report. People are also more likely to ping-pong ,argue or "how do I..." with a human than they are with an automated robot.
Quoted 3 lines
Either way, it isn't kernel specific.... which is what I was trying to address. If it is valuable (which as you demonstrate is debatable,) then it is valuable in bugzilla baseline, not just kernel-bugzilla.
What!? Parsing an oops isn't kernel specific? Version tracking over multiple separate trees as diverse as 2.4 and 2.5 isn't pretty kernel specific? In any case, people could take the kernel bug database, and genericify it, much more easily than somebody could tailor an existing bug tracking application to the needs of the kernel, (which is demonstrated by the fact that the developers are not getting Bugzilla reports).
John.
Quoted 16 lines · John Bradford
[CC list trimmed]
Quoted 13 lines
Quoted 12 lines
Quoted 5 lines
Quoted 4 lines
It could warn the user if they attach an un-decoded oops that their bug report isn't as useful as it could be, and if they mention a distribution kernel version, that it's not a tree that the developers will necessarily be familiar with
Perhaps a more generalized hook into bugzilla for 'validating' a bug report, then code specific validators for kernel work?
Its a nice idea, but I think it's a lot of effort to get it right, when a human can look at the dump, realise its not decoded, and send a request back in hardly any time at all.
I also don't trust things like this where if something goes wrong, we could lose the bug report. People are also more likely to ping-pong ,argue or "how do I..." with a human than they are with an automated robot.
Quoted 4 lines
Quoted 1 line
Either way, it isn't kernel specific.... which is what I was trying to address. If it is valuable (which as you demonstrate is debatable,) then it is valuable in bugzilla baseline, not just kernel-bugzilla.
What!? Parsing an oops isn't kernel specific?
No, no, you mis-understand. A bug report going through some sort of validation filter is applicable to any project. A validation script that checks for a very close match to existing bugs for instance, and asks the submitter about it, would be widely applicable.
Parsing an oops would be a kernel-specific validation filter.
Quoted 3 lines
Version tracking over
multiple separate trees as diverse as 2.4 and 2.5 isn't pretty kernel specific?
No, it isn't. There are a lot of projects out there that use a 'development' and 'stable' tree, and some that use more. bugzilla itself does this. Trolltech's Qt has several version branches. We do have more development branches than most, but we are not unique.
My point is that this is functionality that makes sense for the base version of the bug tracking software, not just for the kernel version.
Quoted 5 lines
In any case, people could take the kernel bug database, and genericify it, much more easily than somebody could tailor an existing bug tracking application to the needs of the kernel, (which is demonstrated by the fact that the developers are not getting Bugzilla reports).
Perhaps, but I'm not convinced that it would be easier to write a kernel bug database from scratch than it would be to improve an existing project to address the kernel's needs. And _that_ is what we were discussing.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
Quoted 10 lines
Quoted 5 lines
In any case, people could take the kernel bug database, and genericify it, much more easily than somebody could tailor an existing bug tracking application to the needs of the kernel, (which is demonstrated by the fact that the developers are not getting Bugzilla reports).
Perhaps, but I'm not convinced that it would be easier to write a kernel bug database from scratch than it would be to improve an existing project to address the kernel's needs. And _that_ is what we were discussing.
Ah, well no wonder we're not agreeing :-), I actually saw the re-writing from scratch as being easier :-).
Maybe I am just in the minority in that I don't find Bugzilla intuitive.
John.
Quoted 6 lines
It's an annoyance to me that the current bugzilla we use can only do 1 way email. Ie, I receive email when things change, but I can't reply to that mail and have my comments auto-added.
Other bugzillas can do this, so I think either some switch needs to be enabled, or theres some extension not present.
(I'm a complete bugzilla weenie, and no nothing about how its set up).
I think it's some extensions that can be used. Jon is the person who knows the Bugzilla tool itself ... Jon, any comments on this?
M.
Quoted 7 lines · Martin J. Bligh
Quoted 6 lines
It's an annoyance to me that the current bugzilla we use can only do 1 way email. Ie, I receive email when things change, but I can't reply to that mail and have my comments auto-added.
Other bugzillas can do this, so I think either some switch needs to be enabled, or theres some extension not present.
(I'm a complete bugzilla weenie, and no nothing about how its set up).
Quoted 6 lines
I think it's some extensions that can be used. Jon is the person who knows the Bugzilla tool itself ... Jon, any comments on this?
M.
There is a script in bugzilla that can be set up with procmail to accept messages for appending comments. Though there are some issues with it that prevent even the mozilla site from enabling it in their own bugzilla. These are noted in
http://bugzilla.mozilla.org/show_bug.cgi?id=44393 as relating to authentication and dealing with vacation/auto-responders.
Perhaps this is an opportunity for someone that wants to work on a bug tracker to enhance this script and contribute it to bugzilla.
Jon
Quoted 8 lines · John Bradford
Following on from yesterday's discussion about there not being much interaction between the kernel Bugzilla and the developers, I began wondering whether Bugzilla might be a bit too generic to be suited to kernel development, and that maybe a system written from the ground up for reporting kernel bugs would be better?
I.E. I am prepared to write it myself, if people think it's worthwhile.
Hopefully you could make it more generic than just for kernel bugs. Ideally it would be nice to be able to have both an interactive submission and a way to mail a version number and get back a questionare to fill in and resubmit. This allows for a custom form for some versions, as well as another mail back listing known bugs fixed in later versions, to avoid reporting fixed bugs.
I'm not sure if it would be possible to make a frontend to bugzilla, I'm not thrilled with the whole thing, but I have no illusions of having enough free time to tackle anything that large.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 10 lines
Quoted 8 lines
Following on from yesterday's discussion about there not being much interaction between the kernel Bugzilla and the developers, I began wondering whether Bugzilla might be a bit too generic to be suited to kernel development, and that maybe a system written from the ground up for reporting kernel bugs would be better?
I.E. I am prepared to write it myself, if people think it's worthwhile.
Hopefully you could make it more generic than just for kernel bugs.
Well, my intention was to write it based around being used for kernel bugs, and let others modify it for their needs, (and presumably Bugzilla was based around being used for reporting bugs in a web browser).
Quoted 5 lines
Ideally it would be nice to be able to have both an interactive submission and a way to mail a version number and get back a questionare to fill in and resubmit. This allows for a custom form for some versions, as well as another mail back listing known bugs fixed in later versions, to avoid reporting fixed bugs.
Interesting - so the first stage in reporting a bug would be to select the latest 2.4 and 2.5 kernels that you've noticed it in, and get a list of known bugs fixed in those versions. Also, if you'd selected the maintainer, (from an automatically generated list from the MAINTAINERS file), it could just search *their* changes in the changelog.
Quoted 3 lines
I'm not sure if it would be possible to make a frontend to bugzilla, I'm not thrilled with the whole thing, but I have no illusions of having enough free time to tackle anything that large.
I'm prepared to have a go at it. This _is_ my kind of area - most of my income this year has come from writing web-based database code :-).
Quoted 1 line
Doing interesting things with little computers since 1979.
Were you doing boring things with large computers before then? :-) :-) :-). Sorry, I'm being silly now :-).
John.
Quoted 8 lines · John Bradford
[snip]
Interesting - so the first stage in reporting a bug would be to select the latest 2.4 and 2.5 kernels that you've noticed it in, and get a list of known bugs fixed in those versions. Also, if you'd selected the maintainer, (from an automatically generated list from the
MAINTAINERSfile), it could just search *their* changes in the changelog.
It's often difficult to pick a maintainer for a bug - it may not be the fault of a single subsystem. As an example, I recently had a problem getting USB and network to function (on kernels 2.5.5x). I noticed that toggling Local APIC would also toggle which of the two devices worked. Disabling ACPI allows both deviecs to function regardless of local APIC.
So, where is the problem?
1) Network driver? It doesn't work with ACPI and both Local APIC and IO-APIC.
2) USB driver? It doesn't work with ACPI and no UP APIC.
3) APIC? Causes weird problems with various drivers when ACPI is turned on.
4) ACPI? Causes weird problems with various drivers when APIC is toggled.
(this exact bug was in Bugzilla, though I hadn't checked there before mailing lkml ;)
I'm not exactly a neophyte to the kernel, and I would have to do a lot more digging to find the right maintainer to send this to. Also, the person(s) to whom the bug is reported will depend on how much debugging work I do, and in what order I do it.
I'm not trying to discourage you - just raising a potential gotcha.
- Steve
Quoted 8 lines
Quoted 6 lines
Interesting - so the first stage in reporting a bug would be to select the latest 2.4 and 2.5 kernels that you've noticed it in, and get a list of known bugs fixed in those versions. Also, if you'd selected the maintainer, (from an automatically generated list from the
MAINTAINERSfile), it could just search *their* changes in the changelog.It's often difficult to pick a maintainer for a bug - it may not be the fault of a single subsystem.
Yes, that's true.
Quoted 6 lines
As an example, I recently had a problem getting USB and network to function (on kernels 2.5.5x).
I noticed that toggling Local APIC would also toggle which of the two devices worked.
Disabling ACPI allows both deviecs to function regardless of local APIC.
Quoted 6 lines
So, where is the problem?
1) Network driver? It doesn't work with ACPI and both Local APIC and IO-APIC.
2) USB driver? It doesn't work with ACPI and no UP APIC.
3) APIC? Causes weird problems with various drivers when ACPI is turned on.
4) ACPI? Causes weird problems with various drivers when APIC is toggled.
The way I imagine it working would be that you could assign it to multiple maintainers, (perhaps with a maximum to discourage the sending of all bugs to everybody, or alternatively, you could lower the priority of a bug sent to multiple people, on the basis that it was more likely to get solved anyway, so you are, in effect, balancing out the attention it gets).
In the case you point out, as it's primarily networking and USB, the bug would get assigned to Andrew Morton, Jeff Garzik, and Greg Kroah-Hartman, who would all be relevant people to contact.
Quoted 7 lines
(this exact bug was in Bugzilla, though I hadn't checked there before mailing lkml ;)
I'm not exactly a neophyte to the kernel, and I would have to do a lot more digging to find the right maintainer to send this to. Also, the person(s) to whom the bug is reported will depend on how much debugging work I do, and in what order I do it.
Good point.
Quoted 1 line
I'm not trying to discourage you - just raising a potential gotcha.
Overall, though, would you rather be presented with a list of categories, or a list of people and what parts of the code they maintain. Personally, I think that a list of people is more intuitive, rather than an abstract list of categories, but I could be wrong.
John.
On Thu, 19 Dec 2002, John Bradford wrote:
| > >Interesting - so the first stage in reporting a bug would be to select | > >the latest 2.4 and 2.5 kernels that you've noticed it in, and get a | > >list of known bugs fixed in those versions. Also, if you'd selected | > >the maintainer, (from an automatically generated list from the | > >MAINTAINERS file), it could just search *their* changes in the changelog. | > > | > It's often difficult to pick a maintainer for a bug - it may not be the | > fault of a single subsystem. | | Yes, that's true.
or maybe it's just difficult to tell which subsystem has a problem...
| > As an example, I recently had a problem getting USB and network to | > function (on kernels 2.5.5x). | > I noticed that toggling Local APIC would also toggle which of the | > two devices worked. | > Disabling ACPI allows both deviecs to function regardless of local APIC. | > | > So, where is the problem? | > 1) Network driver? It doesn't work with ACPI and both Local APIC and | > IO-APIC. | > 2) USB driver? It doesn't work with ACPI and no UP APIC. | > 3) APIC? Causes weird problems with various drivers when ACPI is turned on. | > 4) ACPI? Causes weird problems with various drivers when APIC is toggled. | | The way I imagine it working would be that you could assign it to | multiple maintainers, (perhaps with a maximum to discourage the | sending of all bugs to everybody, or alternatively, you could lower | the priority of a bug sent to multiple people, on the basis that it | was more likely to get solved anyway, so you are, in effect, balancing | out the attention it gets). | | In the case you point out, as it's primarily networking and USB, the | bug would get assigned to Andrew Morton, Jeff Garzik, and Greg | Kroah-Hartman, who would all be relevant people to contact.
Hm, I see this problem as more of a generic interrupt routing or ACPI problem, not networking or USB.
| > (this exact bug was in Bugzilla, though I hadn't checked there before | > mailing lkml ;) | > | > I'm not exactly a neophyte to the kernel, and I would have to do a lot | > more digging to find the right maintainer to send this to. Also, the | > person(s) to whom the bug is reported will depend on how much debugging | > work I do, and in what order I do it. | | Good point. | | > I'm not trying to discourage you - just raising a potential gotcha. | | Overall, though, would you rather be presented with a list of | categories, or a list of people and what parts of the code they | maintain. Personally, I think that a list of people is more | intuitive, rather than an abstract list of categories, but I could be | wrong.
Do we have anyone targeted for interrupt routing problems (PIC, IO APIC, ACPI, etc.)?
Signature · 1 line
~Randy
Quoted 10 lines
| > I'm not trying to discourage you - just raising a potential gotcha. | | Overall, though, would you rather be presented with a list of | categories, or a list of people and what parts of the code they | maintain. Personally, I think that a list of people is more | intuitive, rather than an abstract list of categories, but I could be | wrong.Do we have anyone targeted for interrupt routing problems (PIC, IO APIC, ACPI, etc.)?
No. I nominate Alan :-).
OK, I see your point, but no bug system will ever be perfect. Does that mean there is no point in trying to make a better one? If everybody really thinks it's a waste of time, I won't bother. It just seemed to me that we need something less generic than Bugzilla. Maybe I am wrong, I don't know.
John.
Quoted 12 lines · John Bradford
Quoted 10 lines
| > I'm not trying to discourage you - just raising a potential gotcha. | | Overall, though, would you rather be presented with a list of | categories, or a list of people and what parts of the code they | maintain. Personally, I think that a list of people is more | intuitive, rather than an abstract list of categories, but I could be | wrong.Do we have anyone targeted for interrupt routing problems (PIC, IO APIC, ACPI, etc.)?
Quoted 7 lines
No. I nominate Alan :-).
OK, I see your point, but no bug system will ever be perfect. Does that mean there is no point in trying to make a better one? If everybody really thinks it's a waste of time, I won't bother. It just seemed to me that we need something less generic than Bugzilla. Maybe I am wrong, I don't know.
Don't get discouraged... Our flamethrowers are set to 'stun'. ;)
Bug tracking can get much better (I _hope_!), but I expect it to take some beating on the problem. Keep beating on it.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
On Thu, 19 Dec 2002, Eli Carter wrote:
| John Bradford wrote: | >>| > I'm not trying to discourage you - just raising a potential gotcha. | >>| | >>| Overall, though, would you rather be presented with a list of | >>| categories, or a list of people and what parts of the code they | >>| maintain. Personally, I think that a list of people is more | >>| intuitive, rather than an abstract list of categories, but I could be | >>| wrong. | >> | >>Do we have anyone targeted for interrupt routing problems (PIC, IO APIC, | >>ACPI, etc.)? | > | > | > No. I nominate Alan :-). | > | > OK, I see your point, but no bug system will ever be perfect. Does | > that mean there is no point in trying to make a better one? If | > everybody really thinks it's a waste of time, I won't bother. It just | > seemed to me that we need something less generic than Bugzilla. Maybe | > I am wrong, I don't know. | | Don't get discouraged... Our flamethrowers are set to 'stun'. ;) | | Bug tracking can get much better (I _hope_!), but I expect it to take | some beating on the problem. Keep beating on it.
I agree. I wasn't trying to discourage you. There's much room for improvement IMO.
Signature · 1 line
~Randy
Quoted 1 line
Bug tracking can get much better (I _hope_!), but I expect it to take some beating on the problem. Keep beating on it.
OK. Since we are on the topic. I have some (intending to be) constructive criticisms for the owners of the 2.5 kernel tracker site (not sure exactly who they are but I know mbligh is part of it).
Why are bugs automatically assigned to owners?
If there was an unassigned category that would make it easy to query.
How else are those of us who want to help stabilize the 2.5 kernel supposed
to know which bugs are being worked on and which are not? (Please dont tell me "email". Am I really supposed to email every person who has a bug asking if they are really working on it or not?)
Could you make a list of all the people who have volunteered to be
bugtracker maintainers and their respective kernel pieces.
Also a list of people who arent maintainers but are available to help
could be useful for the owners to assign bugs to.
Thanks.
Hanna
Quoted 9 lines
Quoted 1 line
Bug tracking can get much better (I _hope_!), but I expect it to take some beating on the problem. Keep beating on it.
OK. Since we are on the topic. I have some (intending to be) constructive criticisms for the owners of the 2.5 kernel tracker site (not sure exactly who they are but I know mbligh is part of it).
Why are bugs automatically assigned to owners?
If there was an unassigned category that would make it easy to query.
The "default owner" is someone to dispostion the bug ... not necessarily to fix it.
Quoted 4 lines
How else are those of us who want to help stabilize the 2.5 kernel supposed
to know which bugs are being worked on and which are not? (Please dont tell me "email". Am I really supposed to email every person who has a bug asking if they are really working on it or not?)
Anything in "OPEN" state isn't really assigned to anyone yet. (the state would really better be named "NEW", but it's not). People should move it to "ASSIGNED" if they're working on it.
Quoted 2 lines
Could you make a list of all the people who have volunteered to be
bugtracker maintainers and their respective kernel pieces.
Go to file a new bug, click on the link by the subcategories, and it'll tell you (you'll have to pick the main category first).
Quoted 2 lines
Also a list of people who arent maintainers but are available to help
could be useful for the owners to assign bugs to.
Not sure the best way to work this to be honest ... it may work better as a pull system ... pick something that looks interesting and grab it. You won't have permission to just change the owner field, but you can add comments to bugs, and / or email the owner in question.
There are a bunch of categories that aren't really "owned" as such, and default to khoa or myself. Those are really good candidates to steal ... they'll be owned by bugme-janitors soon to make this more obvious ...
M.
Quoted 4 lines · --On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh"…
Anything in "OPEN" state isn't really assigned to anyone yet. (the state would really better be named "NEW", but it's not). People should move it to "ASSIGNED" if they're working on it.
So the process is to query for all open bugs (but not
assigned) then email each person to let them know you are working on it?
Quoted 3 lines
Go to file a new bug, click on the link by the subcategories, and it'll tell you (you'll have to pick the main category first).
That is convoluted. You have to file a bug to find out who
the subsystem maintainers are? Can you put it somewhere more obvious?
Thanks.
Hanna
Quoted 7 lines
Quoted 3 lines
Anything in "OPEN" state isn't really assigned to anyone yet. (the state would really better be named "NEW", but it's not). People should move it to "ASSIGNED" if they're working on it.
So the process is to query for all open bugs (but not
assigned) then email each person to let them know you are working on it?
Sounds about right. If we had processes ;-)
Quoted 6 lines
Quoted 2 lines
Go to file a new bug, click on the link by the subcategories, and it'll tell you (you'll have to pick the main category first).
That is convoluted. You have to file a bug to find out who
the subsystem maintainers are? Can you put it somewhere more obvious?
Well, you don't have to file one, you just pretend to. But it's not nice, I agree. Jon, is there an easier way to do this, and get all the information in one shot?
M.
Quoted 17 lines · Martin J. Bligh
Quoted 7 lines
Quoted 3 lines
Anything in "OPEN" state isn't really assigned to anyone yet. (the state would really better be named "NEW", but it's not). People should move it to "ASSIGNED" if they're working on it.
So the process is to query for all open bugs (but not
assigned) then email each person to let them know you are working on it?Sounds about right. If we had processes ;-)
Quoted 6 lines
Quoted 2 lines
Go to file a new bug, click on the link by the subcategories, and it'll tell you (you'll have to pick the main category first).
That is convoluted. You have to file a bug to find out who
the subsystem maintainers are? Can you put it somewhere more obvious?
Quoted 8 lines
Well, you don't have to file one, you just pretend to. But it's not nice, I agree. Jon, is there an easier way to do this, and get all the information in one shot?
M.
There is also a link to it on the query page - the Components label. Basically its a link to
http://bugzilla.kernel.org/describecomponents.cgi
We could put a link to it on the main page or elsewhere too if that would be more convenient. It would be easy enough to write a page to show all the component owners in one shot too if desired.
Jon
Quoted 8 lines · --On Friday, December 20, 2002 09:09:31 AM -0600 Jon Tollefson…
There is also a link to it on the query page - the Components label. Basically its a link to
http://bugzilla.kernel.org/describecomponents.cgi
We could put a link to it on the main page or elsewhere too if that would be more convenient. It would be easy enough to write a page to show all the component owners in one shot too if desired.Jon
Hi Jon,
A link to this on the home page would be great. Also if you
could add the FAQ I wrote im sure people would appreciate it. Also if you could add links back to the home page from the query page that would be cool ;)
Thanks.
Hanna
Quoted 13 lines · Hanna Linder
Quoted 8 lines · --On Friday, December 20, 2002 09:09:31 AM -0600 Jon Tollefson…
There is also a link to it on the query page - the Components label. Basically its a link to
http://bugzilla.kernel.org/describecomponents.cgi
We could put a link to it on the main page or elsewhere too if that would be more convenient. It would be easy enough to write a page to show all the component owners in one shot too if desired.Jon
Hi Jon,
Quoted 11 lines
A link to this on the home page would be great. Also if you
could add the FAQ I wrote im sure people would appreciate it. Also if you could add links back to the home page from the query page that would be cool ;)Thanks.
Hanna
I think it would be a great a idea to put a link to the faq and component page on the front page. I'll see if I can find a spot to link to the main page on the query page too.
Normally what I do is package up changes to the kernel bugzilla into an rpm and then hand that to OSDL to install. I currently have a few other changes pending too so I will include the above updates as well. I was thinking of building a new rpm sometime in the first week or two of January - after the holidays when I would be around more- if that is not too late.
Jon
Quoted 6 lines · Hanna Linder
Quoted 3 lines
Anything in "OPEN" state isn't really assigned to anyone yet. (the state would really better be named "NEW", but it's not). People should move it to "ASSIGNED" if they're working on it.
So the process is to query for all open bugs (but not
assigned) then email each person to let them know you are working on it?
Why generate noise ?
Query bugs.
Find something interesting.
Fix it.
THEN email person (or better yet, add to bugzilla entry).
Flooding the database with "I'm working on this" reports buys absolutely nothing.
Quoted 5 lines
Quoted 2 lines
Go to file a new bug, click on the link by the subcategories, and it'll tell you (you'll have to pick the main category first).
That is convoluted. You have to file a bug to find out who
the subsystem maintainers are? Can you put it somewhere more obvious?
I think you're misunderstanding how things work. The view you seem to have is to use bugzilla to find bugs, and get a list of people who to email. This shuts out the rest of the world who are watching that bug in bugzilla.
If you want to add to a bug reported in bugzilla, forget email, just _use the tool_.
Dave
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 5 lines · --On Friday, December 20, 2002 10:35:27 AM +0000 Dave Jones…
If you want to add to a bug reported in bugzilla, forget email, just
_usethetool_.Dave
Thanks Dave,
My ultimate goal is to help stabilize 2.5 by getting
more people using this kernel tracker thereby increasing the patches and testing on lkml ;)
This thread has answered most my questions and I am
going to write up what I have learned to add it to the documentation on the site. As with most things in Linux Kernel development, dont ask to do it, just write it. Expect some documentation soon...
Hanna
Quoted 4 lines · --On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh"…
There are a bunch of categories that aren't really "owned" as such, and default to khoa or myself. Those are really good candidates to steal ... they'll be owned by bugme-janitors soon to make this more obvious ...
OK. Which categories are not owned? Anything with you or khoa as owners? Do I have to pretend to file a bug to find out ;)
Hanna
Quoted 6 lines
Quoted 4 lines
There are a bunch of categories that aren't really "owned" as such, and default to khoa or myself. Those are really good candidates to steal ... they'll be owned by bugme-janitors soon to make this more obvious ...
OK. Which categories are not owned? Anything with you or khoa as owners?
More or less, yes. There are a couple of categories I really own, eg NUMA/discontigmem, and I'll probably look after ia32 specific bugs unless Linus wants his category back ;-)
Will switch to bugme-janitors in a few days, then will all be much more obvious
M.
On Thu, 19 Dec 2002, Martin J. Bligh wrote:
| >> There are a bunch of categories that aren't really "owned" as such, | >> and default to khoa or myself. Those are really good candidates to | >> steal ... they'll be owned by bugme-janitors soon to make this more | >> obvious ... | > | > OK. Which categories are not owned? Anything with you or khoa as owners? | | More or less, yes. There are a couple of categories I really own, eg | NUMA/discontigmem, and I'll probably look after ia32 specific bugs | unless Linus wants his category back ;-) | | Will switch to bugme-janitors in a few days, then will all be much more | obvious
What does this last sentence mean?
Signature · 1 line
~Randy
Quoted 15 lines
| >> There are a bunch of categories that aren't really "owned" as such, | >> and default to khoa or myself. Those are really good candidates to | >> steal ... they'll be owned by bugme-janitors soon to make this more | >> obvious ... | > | > OK. Which categories are not owned? Anything with you or khoa as | > owners? | | More or less, yes. There are a couple of categories I really own, eg | NUMA/discontigmem, and I'll probably look after ia32 specific bugs | unless Linus wants his category back ;-) | | Will switch to bugme-janitors in a few days, then will all be much more | obvious
Quoted 1 line
What does this last sentence mean?
Instead of categories that don't have a "real" owner defaulting back to me or Khoa, they'll go to bugme-janitors, which is an alias. That way we'll have better coverage, and it'll be obvious which things aren't really owned.
M
A message that is not in the archive (sent off-list or not yet received): 31080000.1040418947@w-hlinder
Re: Dedicated kernel bug database + documentaion
Here is my first draft of cleaning up some of the definitions and adding a FAQ for the kernel tracker bugzilla. Comments and flames welcome.
Hanna
-------
Status
OPEN - A new bug that no one is working on. Bugs in this state may be accepted, and become ASSIGNED. The default owner (in charge of tracking the bug) is the subsystem maintainer or the bugme-janitors mailing list.
ASSIGNED - This bug is assigned to someone who thinks they can fix it.
Quoted 1 line
From here bugs typically move to RESOLVED or REJECTED.
RESOLVED - A fix has been made, and it is awaiting more testing.
Quoted 1 line
From here bugs are usually either CLOSED or APPROVED.
APPROVED- The fix has been tested. But is not accepted into the mainline kernel.
REJECTED-The bug has not been fixed. Possible reasons for rejections are INVALID, DUPLICATE, UNREPRODUCIBLE, or INSUFFICIENT_DATA.
DEFERRED- The bug may or may not be fixed later.
CLOSED - The fix has been accepted into the mainline kernel.
Resolution
The resolution field indicates what happened to this bug.
No resolution yet: All bugs which are in one of the "open" states (meaning the state has no associated resolution) have the resolution set to blank. All other bugs will be marked with one of the following resolutions.
CODE_FIX - A fix(patch) for this bug has been generated.
PATCH_ALREADY_AVAILABLE - This problem has been fixed before and there is a patch available for it.
INVALID - The problem described is not a bug.
WILL_NOT_FIX - The problem described is a bug which will never be fixed.
WILL_FIX_LATER - The problem described is a bug which will not be fixed in this version.
DUPLICATE - The problem is a duplicate of an existing bug. Marking a bug duplicate requires the bug number of the duplicate and that number will be placed in the bug description.
UNREPRODUCIBLE - All attempts at reproducing this bug were futile, reading the code produces no clues as to why this behavior would occur. If more information appears later, please re-assign the bug, for now, file it.
INSUFFICIENT_DATA - There is not enough information to resolve this bug.
--------------
Frequently Asked Questions
Q. How do I know if a bug is being worked on or not?
A. If it is not ASSIGNED to anyone then it is not being worked on.
Q. Why are the subsystem maintainers in kernel tracker sometimes different than the person listed in the MAINTAINER file?
A. The subsystem maintainers in kernel tracker are volunteers to help track bugs in an area they are interested in. Sometimes they are the same person as on kernel.org sometimes they are not. There are still some categories with no maintainers so more volunteers are needed.
Q. What does a subsystem maintainer do?
A. He or She will track new bugs and assign them to people or reject it for various reasons. They periodically check to make sure things are getting worked on and review fixes to make sure they are well written.
Q. If a bug has an owner does that mean they are workig on it?
A. No. If it is not in the ASSIGNED state then no one is working on it. The owner defaults to the subsytem maintainer. However, anyone who wants to submit a patch or add more info to a bug can do so. If the bug is reassigned to someone then the owner field will reflect that change.
Q. Can anyone add comments to a bug?
A. Yes but you will need to sign up for an account first.
Q. Who can change the status of a bug?
A. Only the subsystem maintainer. If you want to update a bug put your comments in the comment or attachment fields.
Q. What is the difference between RESOLVED, APPROVED and CLOSED?
A. RESOLVED really should be renamed UNTESTED_FIX. That is when a fix is available but needs more testing. APPROVED is very poorly named and should be TESTED_FIX. This is the last step before CLOSED. CLOSED means the fix has been accepted into the mainline kernel.
Q. What would cause a bug to be REJECTED?
A. Probably the two most common reasons are the problem is a DUPLICATE of another bug or the report is just badly written and there is not enough info to do anything about it.
Re: Dedicated kernel bug database + documentaion
Quoted 3 lines · Hanna Linder
Here is my first draft of cleaning up some of the definitions and adding a FAQ for the kernel tracker bugzilla. Comments and flames welcome.
Very enlightening for me. Thanks! A nice _prominant_ link to this on the bugzilla page (near the top with a nice graphic) would be great too. :)
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
Re: Dedicated kernel bug database + documentaion
In reply to Hanna Linder| ------- | Status | | OPEN - A new bug that no one is working on. Bugs in this state may | be accepted, and become ASSIGNED. The default owner (in charge of tracking | the bug) is the subsystem maintainer or the bugme-janitors mailing list.
Do new bugs go straight to OPEN with a default owner?
Where does someone sign up for this new mailing list?
Signature · 1 line
~Randy
Re: Dedicated kernel bug database + documentaion
Quoted 5 lines
| OPEN - A new bug that no one is working on. Bugs in this state may | be accepted, and become ASSIGNED. The default owner (in charge of tracking | the bug) is the subsystem maintainer or the bugme-janitors mailing list.Do new bugs go straight to OPEN with a default owner?
Yes. OPEN should really be called NEW. Will try to fix that as it seems to be causing confusion. I don't particularly like the naming of RESOLVED or ACCEPTED either, but we'll have to see how hard it is to change these things.
Quoted 1 line
Where does someone sign up for this new mailing list?
Email me. But I'm going to keep it to a small tight group for now, will see how it works out from there. At the moment bugs that have not real owner just go to me or Khoa, so this is a step up, even if it's not perfect.
M.
Only the owner of the bug (or an admin) can change that, I think. However, as you file the bug, you could change the default owner to yourself, which would fix it. I'll fix this one for you.
M.
Quoted 22 lines · --On Friday, December 20, 2002 13:15:48 -0800 Hanna Linder <[email protected]>…
Quoted 1 line · --On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh"…
People should move it to "ASSIGNED" if they're working on it.
I just created a bug to put better documentation on the site about how this stuff works.
However, It won't let me assign it to myself even though I submitted it. Are the only people who are allowed to change status the subsystem maintainer of the category? If we volunteer to be part of the bugme-janitors mailing list then could we change status of bugs?
I understand you dont want the whole world messing with the database so if the answer is no you cant touch it then that is fine.
Thanks.
Hanna
Quoted 4 lines · Martin J. Bligh
Only the owner of the bug (or an admin) can change that, I think. However, as you file the bug, you could change the default owner to yourself, which would fix it. I'll fix this one for you.
Quoted 30 lines
M.
Quoted 22 lines · --On Friday, December 20, 2002 13:15:48 -0800 Hanna Linder <[email protected]>…
Quoted 1 line · --On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh"…
People should move it to "ASSIGNED" if they're working on it.
I just created a bug to put better documentation on the site about how this stuff works.
However, It won't let me assign it to myself even though I submitted it. Are the only people who are allowed to change status the subsystem maintainer of the category? If we volunteer to be part of the bugme-janitors mailing list then could we change status of bugs?
I understand you dont want the whole world messing with the database so if the answer is no you cant touch it then that is fine.
Thanks.
Hanna
The way it is setup now is that mostly only component owners can move a bug to the assigned state. A submitter of a bug and the owner of a bug can change any other aspect of the bugs that they submit or own respectively. And anyone can submit comments to any bug.
Jon
Quoted 7 lines · --On Friday, December 20, 2002 09:27:24 PM -0600 Jon Tollefson…
Quoted 6 lines · Martin J. Bligh
Only the owner of the bug (or an admin) can change that, I think. However, as you file the bug, you could change the default owner to yourself, which would fix it. I'll fix this one for you.
Quoted 2 lines
--On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <[email protected]> wrote:
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
People should move it to "ASSIGNED" if they're working on it.
The way it is setup now is that mostly only component owners can move a bug to the assigned state. A submitter of a bug and the owner of a bug can change any other aspect of the bugs that they submit or own respectively. And anyone can submit comments to any bug.
Jon and Martin,
You seem to be saying different things. If the submitter wants
to take the bug they need to be able to change the status to ASSIGNED. But according to Jon (and my experience) I was not able to change the status or take a bug (although I could change the owner).
Is it possible to make it so an owner can change the status?
If not you should change the FAQ to describe the procedure for letting people know you are working on a bug.
Thanks.
Hanna
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines
Why are bugs automatically assigned to owners?
If there was an unassigned category that would make it easy to query.
Query for "NEW" status for a component and do not put anything into "owner" fireld.
Quoted 4 lines
How else are those of us who want to help stabilize the 2.5 kernel supposed
to know which bugs are being worked on and which are not? (Please dont tell me "email". Am I really supposed to email every person who has a bug asking if they are really working on it or not?)
Of course.
Quoted 2 lines
Could you make a list of all the people who have volunteered to be
bugtracker maintainers and their respective kernel pieces.
This is a reasonable request, IMHO.
Quoted 2 lines
Also a list of people who arent maintainers but are available to help
could be useful for the owners to assign bugs to.
That's putting a cart in front of a horse. Such people have to execute a simple Bugzilla to get lists, then select bugs which they like. This way the overhead of maintaining such lists disappears instantly.
-- Pete
Quoted 6 lines · --On Thursday, December 19, 2002 06:59:30 PM -0500 Pete Zaitcev…
Quoted 3 lines
Why are bugs automatically assigned to owners?
If there was an unassigned category that would make it easy to query.Query for "NEW" status for a component and do not put anything into "owner" fireld.
If there was a NEW field that would be exactly what I was
asking for. When I do a query the only options I see are: OPEN, ASSIGNED, RESOLVED, APPROVED, REJECTED, DEFERRED, CLOSED. Where is the NEW? Is there somewhere else to do queries?
Quoted 7 lines
Quoted 2 lines
Also a list of people who arent maintainers but are available to help
could be useful for the owners to assign bugs to.That's putting a cart in front of a horse. Such people have to execute a simple Bugzilla to get lists, then select bugs which they like. This way the overhead of maintaining such lists disappears instantly.
Im trying to help make it easier for such people to get a list of bugs to start working on. If it looks like everything already has an owner it looks like there is nothing to do. Im just trying to figure out how to use it and hopefully help other people do the same thing.
Thanks a lot.
Hanna (obviously not a bugzilla user before)
Quoted 7 lines
Date: Thu, 19 Dec 2002 16:19:03 -0800
From: Hanna Linder <[email protected]>Quoted 4 lines
Quoted 3 lines
Why are bugs automatically assigned to owners?
If there was an unassigned category that would make it easy to query.
Quoted 7 lines
Quoted 2 lines
Query for "NEW" status for a component and do not put anything into "owner" fireld.
If there was a NEW field that would be exactly what I was
asking for. When I do a query the only options I see are: OPEN, ASSIGNED, RESOLVED, APPROVED, REJECTED, DEFERRED, CLOSED. Where is the NEW? Is there somewhere else to do queries?
OK, I'm sorry. This is a little different from what we have at bugizlla.redhat.com. I suspect OSDL's OPEN roughly corresponds to NEW. They appear to use Bugzilla which closely resembles the mother of all them at Mozilla.
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
Also a list of people who arent maintainers but are available to help
could be useful for the owners to assign bugs to.That's putting a cart in front of a horse. Such people have to execute a simple Bugzilla to get lists, then select bugs which they like. This way the overhead of maintaining such lists disappears instantly.
Quoted 5 lines
Im trying to help make it easier for such people to get a list of bugs to start working on. If it looks like everything already has an owner it looks like there is nothing to do. Im just trying to figure out how to use it and hopefully help other people do the same thing.
I see the point. I would say, having an owner does not mean much. Owner is just a person who makes sure bugs do not get lost. You can work on my bugs if you'd like :)
I understand now that I carry a whole load of misconceptions caused by extensive use of a slighly different process at Red Hat. Perhaps we ought to tap into Mozilla people expirience.
-- Pete
Quoted 3 lines · --On Thursday, December 19, 2002 07:24:19 PM -0500 Pete Zaitcev…
I see the point. I would say, having an owner does not mean much. Owner is just a person who makes sure bugs do not get lost. You can work on my bugs if you'd like :)
Well thank you :) My argument is that there should be a
way USING THE TOOL to determine which bugs are available to be worked on. Do you seriously want 2000 people emailing you privately
asking if you are working on your bugs? I suspect since this bugzilla
is so brand new that there should be something the database people can do to facilitate this.
I agree there should be people making sure the bugs don't get
ignored, but do they have to be assigned as owners? Could there be a hierarchical set up of subsystem maintainer contact and then actual bug owner?
Hanna
Quoted 4 lines · Hanna Linder
Well thank you :) My argument is that there should be a
way USING THE TOOL to determine which bugs are available to be worked on. Do you seriously want 2000 people emailing you privately asking if you are working on your bugs?
A periodic (once a month?) automated ping from bugzilla would be good. "You have these bugs assigned to you..." status report type thing.
Dave
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 2 lines · Dave Jones
A periodic (once a month?) automated ping from bugzilla would be good. "You have these bugs assigned to you..." status report type thing.
I believe it already does that.
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 3 lines · Hanna Linder
Im trying to help make it easier for such people to get a list of bugs to start working on. If it looks like everything already has an owner it looks like there is nothing to do.
Just because a bug is 'owned' does not stop someone else working on it. That would be silly. All the owner field says is, "if someone is interested in this bug, and they happen to fix before $owner does, $owner would like to know about it." This way $owner can reject bad fixes, or get further clues as to whats actually causing the problem.
Quoted 1 line
Hanna (obviously not a bugzilla user before)
Obviously 8-)
Dave
Signature · 2 lines
| Dave Jones. http://www.codemonkey.org.uk | SuSE Labs
Quoted 12 lines · Dave Jones
Quoted 3 lines · Hanna Linder
Im trying to help make it easier for such people to get a list of bugs to start working on. If it looks like everything already has an owner it looks like there is nothing to do.
Just because a bug is 'owned' does not stop someone else working on it. That would be silly. All the owner field says is, "if someone is interested in this bug, and they happen to fix before $owner does, $owner would like to know about it." This way $owner can reject bad fixes, or get further clues as to whats actually causing the problem.
Quoted 3 lines
Quoted 1 line
Hanna (obviously not a bugzilla user before)
Obviously 8-)
I'm new to bugzilla too... I noticed there is a link "Give me a clue about how to use this form." I think that needs to be at the top of the query form, with a nice '?' graphic beside it. I suspect that would help a lot.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
Hmmm.
It seems to me that a kernel bug tracking system has to have a pretty good knowledge (database) of the kernel(s) it is meant to track. Essentially, a user who has a problem can usually identify what the problem is ("my external firewire HD doesn't work"), but not where the cause may be (interrupts / filesystem drivers / mount tools / scsi generic / sbp2 / ieee1394 / pci / ACPI / APIC / VM / ...).
So, if a user could enter some keywords for their problem and get a list of possible subsystems that it depends on (along with maintainers for those subsystems), we'd be getting somewhere.
For the usb / apic / acpi / rtl8139 problem, I would enter something like USB keyboard, 8139too, local APIC, IO-APIC, VIA kt333, kernel 2.5.45-51
The wizardly database (knowing what each "leaf device" depends on), then finds the intersection of subsystems that affect all (or some specified percentage) of the things the keywords match.
This requires a tree of dependencies (pretty much there - look at what headers are included in each source file) for each driver.
Of course, there are things that everything depends on (VM), which would probably want to be left out unless no higher level common ancestor of the problems can be found.
The trouble with searching a flat bug database is that you have to know what you're looking for. If the bug tracker actually helped figure out the problem (where possible, of course), that would be a boon.
John Bradford wrote:
[snip snip]
Quoted 6 lines
Quoted 6 lines
| Overall, though, would you rather be presented with a list of | categories, or a list of people and what parts of the code they | maintain. Personally, I think that a list of people is more | intuitive, rather than an abstract list of categories, but I could be | wrong.
Quoted 7 lines
Quoted 4 lines
Do we have anyone targeted for interrupt routing problems (PIC, IO APIC, ACPI, etc.)?
No. I nominate Alan :-).
Agreed. (can he be elected without knowing he's on the ballot? :)