Dedicated kernel bug database

Dedicated kernel bug database

[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.

Re: Dedicated kernel bug database

[Brian Jackson]

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 

John Bradford writes: 

> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
 

Re: Dedicated kernel bug database

[Eli Carter]

John Bradford wrote:
> 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.)

> 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.

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.

> 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?

> 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?

> 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 `-------------------------------------------------

Re: Dedicated kernel bug database

[Dave Jones]

On Thu, Dec 19, 2002 at 11:48:16AM -0600, Eli Carter wrote:
 > >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).

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

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: Dedicated kernel bug database

[Eli Carter]

Dave Jones wrote:
> On Thu, Dec 19, 2002 at 11:48:16AM -0600, Eli Carter wrote:
[snip]
>  > >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.

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 `-------------------------------------------------

Re: Dedicated kernel bug database

[John Bradford]

>  > >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).

> 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 :-).

> 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.

Re: Dedicated kernel bug database

[Bill Davidsen]

On Thu, 19 Dec 2002, John Bradford wrote:

> 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.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Dedicated kernel bug database

[John Bradford]

[CC list trimmed]

> >  > >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.
> 
> 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.

Re: Dedicated kernel bug database

[Dave Jones]

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.

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.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Dedicated kernel bug database

[Eli Carter]

John Bradford wrote:
> [CC list trimmed]
> 
> 
>>> > >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.
>>
>>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.

 >  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.

 > 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 `-------------------------------------------------

Re: Dedicated kernel bug database

[Randy.Dunlap]

[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...

-- 
~Randy

Re: Dedicated kernel bug database

[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.

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).

> 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.

> 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 :-).

> 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.

Re: Dedicated kernel bug database

[John Bradford]

>  > > 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.

> 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*.

>  > 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.

> 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.

> 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.

>  > 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.

>  > 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 :-)

> 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.

Re: Dedicated kernel bug database

[John Bradford]

> > 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.

Re: Dedicated kernel bug database

[Stephen Wille Padnos]

John Bradford wrote:

> [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
>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.  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

Re: Dedicated kernel bug database

[Randy.Dunlap]

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.)?

-- 
~Randy

Re: Dedicated kernel bug database

[John Bradford]

> >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.

> 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.

> (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.

John.

Re: Dedicated kernel bug database

[Randy.Dunlap]

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.

-- 
~Randy

Re: Dedicated kernel bug database

[John Bradford]

> | > 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.

Re: Dedicated kernel bug database

[Eli Carter]

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.

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

[Stephen Wille Padnos]

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]

>>| 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 :-).
>
Agreed.  (can he be elected without knowing he's on the ballot? :)

Re: Dedicated kernel bug database

[Hanna Linder]

> 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

Re: Dedicated kernel bug database

[Pete Zaitcev]

> 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.

> 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.

> 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.

> 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

Re: Dedicated kernel bug database

[Hanna Linder]

--On Thursday, December 19, 2002 06:59:30 PM -0500 Pete Zaitcev <zaitcev@redhat.com> wrote:

>> 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?

>> 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)

Re: Dedicated kernel bug database

[Pete Zaitcev]

> Date: Thu, 19 Dec 2002 16:19:03 -0800
> From: Hanna Linder <hannal@us.ibm.com>

> >> 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?

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.

> >> 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.

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

Re: Dedicated kernel bug database

[Hanna Linder]

--On Thursday, December 19, 2002 07:24:19 PM -0500 Pete Zaitcev <zaitcev@redhat.com> wrote:

> 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

	

Re: Dedicated kernel bug database

[Martin J. Bligh]

>> 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.
 	
> 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.
 
> 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).
 
> 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.

Re: Dedicated kernel bug database

[Hanna Linder]

--On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <mbligh@aracnet.com> wrote:

> 
> 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?

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

Re: Dedicated kernel bug database

[Hanna Linder]

--On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <mbligh@aracnet.com> 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?
Do I have to pretend to file a bug to find out ;) 

Hanna

Re: Dedicated kernel bug database

[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?

Sounds about right. If we had processes ;-)

>> 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.

Re: Dedicated kernel bug database

[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?

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.

Re: Dedicated kernel bug database

[Randy.Dunlap]

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?

-- 
~Randy

Re: Dedicated kernel bug database

[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?
>|
>| 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?

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

Re: Dedicated kernel bug database

[Martin J. Bligh]

> 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.

Re: Dedicated kernel bug database

[Martin J. Bligh]

> 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.

Re: Dedicated kernel bug database

[Martin J. Bligh]

> 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.

> - 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.

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.

Re: Dedicated kernel bug database

[John Bradford]

[CC list trimmed]

> > 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.

> > - 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.
> 
> Have you actually looked at the maintainers file?

Yes.

> It's a twisted mess of outdated information,

Then it should be updated, that is nothing to do with Bugzilla.

> in no well formated order.

Looks easy enough to parse with regular expressions to me.

> 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.

> 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.

Re: Dedicated kernel bug database

[Dave Jones]

On Thu, Dec 19, 2002 at 04:19:03PM -0800, Hanna Linder wrote:

 > 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.

 > Hanna (obviously not a bugzilla user before)

Obviously 8-)

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Dedicated kernel bug database

[Dave Jones]

On Thu, Dec 19, 2002 at 05:01:41PM -0800, Hanna Linder wrote:
 
 > 	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

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Dedicated kernel bug database

[Dave Jones]

On Thu, Dec 19, 2002 at 06:01:34PM -0800, Hanna Linder wrote:

 > > 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.

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

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Dedicated kernel bug database

[Dave Jones]

On Fri, Dec 20, 2002 at 09:48:53AM +0000, John Bradford wrote:
 > > > 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

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Dedicated kernel bug database

[Russell King]

On Fri, Dec 20, 2002 at 10:32:12AM +0000, Dave Jones wrote:
> 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.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Dedicated kernel bug database

[Jon Tollefson]

On Thu, 2002-12-19 at 20:20, Martin J. Bligh wrote:
> >> 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 ;-)
> 
> >> 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.
> 
> 
> 

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

Re: Dedicated kernel bug database

[Eli Carter]

Dave Jones wrote:
> On Thu, Dec 19, 2002 at 04:19:03PM -0800, Hanna Linder wrote:
> 
>  > 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.
> 
>  > 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 `-------------------------------------------------

Re: Dedicated kernel bug database

[Martin J. Bligh]

> 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 ...

>> Have you actually looked at the maintainers file?
>
> Yes.
>
>> 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).

>> 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.

>> 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.

Re: Dedicated kernel bug database

[Jon Tollefson]

On Thu, 2002-12-19 at 21:35, Martin J. Bligh wrote:
> > 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.
> 
> 

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 

Re: Dedicated kernel bug database

[Hanna Linder]

--On Friday, December 20, 2002 10:35:27 AM +0000 Dave Jones <davej@codemonkey.org.uk> wrote:

> 
> If you want to add to a bug reported in bugzilla, forget email,
> just _use the tool_.
> 
> 		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

Re: Dedicated kernel bug database + documentaion

[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.

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. 
>From here bugs typically move to RESOLVED or REJECTED.

RESOLVED - A fix has been made, and it is awaiting more testing. 
>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

[Randy.Dunlap]

| -------
| 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?

-- 
~Randy

Re: Dedicated kernel bug database + documentaion

[Eli Carter]

Hanna Linder wrote:
> 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

[Martin J. Bligh]

>| 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.
 
> 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.

Re: Dedicated kernel bug database

[Hanna Linder]

--On Friday, December 20, 2002 09:09:31 AM -0600 Jon Tollefson <kniht@us.ibm.com> wrote:

> 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

Re: Dedicated kernel bug database

[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.

M.


--On Friday, December 20, 2002 13:15:48 -0800 Hanna Linder <hannal@us.ibm.com> wrote:

> --On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <mbligh@aracnet.com> wrote:
> 
>> 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
> 
> 

Re: Dedicated kernel bug database

[Jon Tollefson]

On Fri, 2002-12-20 at 20:52, Martin J. Bligh wrote:
> 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.
> 
> 
> --On Friday, December 20, 2002 13:15:48 -0800 Hanna Linder <hannal@us.ibm.com> wrote:
> 
> > --On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <mbligh@aracnet.com> wrote:
> > 
> >> 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

Re: Dedicated kernel bug database

[Jon Tollefson]

On Fri, 2002-12-20 at 17:52, Hanna Linder wrote:
> --On Friday, December 20, 2002 09:09:31 AM -0600 Jon Tollefson <kniht@us.ibm.com> wrote:
> 
> > 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
> 
> 
> 


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

Re: Dedicated kernel bug database

[Hanna Linder]

--On Friday, December 20, 2002 09:27:24 PM -0600 Jon Tollefson <kniht@us.ibm.com> wrote:

> On Fri, 2002-12-20 at 20:52, Martin J. Bligh wrote:
>> 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.

>> > --On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <mbligh@aracnet.com> wrote:
>> > 
>> >> 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