Re: Dedicated kernel bug database

Re: Dedicated kernel bug database

[Dan Kegel]

Hanna Linder wrote:

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

When I first looked at the query form, I was overwhelmed by the
list of states.  Clicking on the link above the list takes you to
http://bugzilla.kernel.org/queryhelp.cgi#status
which helps a bit.  (I'm kind of used to a shorter list of states, e.g.
"new / assigned / verifyfix / closed", but bugzilla's list doesn't
look *too* complicated.)

-- 
Dan Kegel
Linux User #78045
http://www.kegel.com

Re: Dedicated kernel bug database

[Adam J. Richter]

On 2002-12-20, Dave Jones wrote:
>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.

	"I'm working on this" messages (in my experience in lkml at
least) help people avoid duplication of effort, and perhaps sometimes
help multiple people who want to work on the same bug find each other.

	I think the "noise" would mostly be a user interface issue.
Imagine, for example, if the "I'm working on this" messages were
consolidated into a single link that said something like "4 people are
working on this bug", which you could click on for the details.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: Dedicated kernel bug database

[Hell.Surfers]

[-- Attachment #1: Type: text/plain, Size: 124 bytes --]

What are your ideas???

Regards, Dean.

On 	Fri, 20 Dec 2002 09:48:53 +0000 (GMT) 	John Bradford <john@grabjohn.com> wrote:

[-- Attachment #2: Type: message/rfc822, Size: 3081 bytes --]

From: John Bradford <john@grabjohn.com>
To: mbligh@aracnet.com (Martin J. Bligh)
Cc: linux-kernel@vger.kernel.org
Subject: Re: Dedicated kernel bug database
Date: Fri, 20 Dec 2002 09:48:53 +0000 (GMT)
Message-ID: <200212200948.gBK9mrXh000326@darkstar.example.net>

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

[John Bradford]

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

> What are your ideas???

* Automatic parsing of things like .config files and oopsen.

* Version tracking that is more suited to a codebase that has at least
  5 very active trees.

* Fully controlable by E-Mail, not only web.

Those are the ones I'm most interested in initially.  Other things can
follow.

I'd had a lot of comments saying that it would be better to either add
these ideas to Bugzilla, or to write a generic bug database, and not
make it specific to kernel development.

The reasons I'm _not_ doing either of those is mostly:

* I don't like Bugzilla at all

* It's easy to make a kernel-specific bug database generic, and not so
  easy to make a generic database kernel-specific

Incidently, can your TV set top box browse the web, or just send
E-Mail?  It would be quite cool if you could go through the bug
database using it :-)

John.

Re: Dedicated kernel bug database

[Nicolas Mailhot]

[-- Attachment #1: Type: text/plain, Size: 3621 bytes --]

|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 assume you're talking about :
http://bugzilla.kernel.org/show_bug.cgi?id=10

As the reporter, I'll tell you plainly bugzilla rocks for this.

This bug was first reported in linux-kernel, then was picked in the 2.5 problem 
reports, then (when bugzilla.kernel.org) was announced reported again in 
bugzilla.

Bugzilla enabled the report to be ping-ponged among maintainers until someone 
accepted it. And it can be found by other people now (note you missed the linux 
kernel  report when you posted this). No one was interested before the bugzilla
report.

Bugzilla can be a pain sometimes, it's not intuitive, it's suffering yet from its
hackish bastard origin, but it works, lots of projects are using it (both because
its so easy to deploy and people are familiar with it - try rt
I-need-30+-perl-packages-to-work-only-I-use hell for example) and it's improving.

2.17.1 (seen both at http://bugzilla.mozilla.org/ and http://bugzilla.redhat.com/)
is a *huge* improvement, I can't wait for it to be released for everyone (right now
the bugzilla team has a hard time integrating all the features everyone and his dog
have been contributing back to the project lately).

All bugzilla's I've seen so far would benefit from better version tracking.
All bugzilla's I've seen so far would benefit from better UI.

The problems raised in this thread are pretty generic. They should be tackled a generic
way in the original project.

However I wouldn't even touch any other bug reporting system. Others (like rt) boast a
better original design ; the truth is they have their own warts but not a community
the size of bugzilla to find/fix them (and I'm not even talking about security audits).

Once you've grokked bugzilla (which I freely admit is long and painful) you'll find it's
actually rather powerful and you'll be trained to interact with :
- mozilla bugzilla
- kernel bugzilla
- apache bugzilla
- gnome bugzilla
- kde bugzilla
- abiword bugzilla
- red hat bugzilla

and so on (and all of these deployments have useful tweaks that trickle back in the 
original bugzilla)

Not having to learn a new UI to report a bug in another project is quite nice. I know I'd 
have thought twice about the feedback I've given to various organizations otherwise.

Regards,

-- 
Nicolas Mailhot
Not linux-kernel subscribed, sometimes reading the archives, sometimes not

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Dedicated kernel bug database

[Heater, Daniel (IndSys, GEFanuc, VMIC)]

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

I'm in that minority with you then...

However, there may be an existing system that's *closer* to the needs of the
kernel than bugzilla.

I was looking at this the other day for my companies purposes. These two
looked
promising to me, but I have not gotten around to trying them.

http://www.bestpractical.com/rt//

http://myrapid.com/webcall/

Re: Dedicated kernel bug database

[Justin Pryzby]

On Thu, Dec 19, 2002 at 01:53:29PM -0500, Dave Jones wrote:
> 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).
> 
> It's an annoyance to me that the current bugzilla we use can only
> 
> 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

I can't say I'm partial to bugzilla either; the reasons above are valid.
I think it could be very useful to have a bugtracking system written by
someone@kernel.org (or at least have someone@kernel.org who is intimitely
familiar with the bugtracking code).  The above dislikes of bugzilla are
all fixable, and it may be easier for someone to do it from scratch than
to try to decode someone else's messy code (I wonder if there is a
bugzilla for bugzilla bugs).

Many of the complaints about current postings, however, could possibly
be fixed by nicifying the kernel webpages (many people don't know much
about ``distribution kernels,'' and might happily try other kernels if
they knew how).

Another part of the problem is that there is no _official_ way of
submitting bugs.  Were someone official to say ``all bugs go to bugzilla,''
(or kzilla, as the case may be), there would certainly be a better
response.  Whatever the current official bugtracking mechanism is, it
should appear on the lkml webpage (atm, it does not).

Justin

re: Dedicated kernel bug database

[Dan Kegel]

John Bradford <john@grabjohn.com> 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.

Quoting Linus (http://marc.theaimsgroup.com/?l=linux-kernel&m=103911905214446&w=2):
> And many things _can_ be done without throwing out old designs.
> Implementation improvements are quite possible without trying to make
> something totally new to the outside. ...
> 
> Not throwing out the baby with the bath-water doesn't mean that you cannot
> improve the system. I'm only arguing against stupid people who think they
> need a revolution to improve - most real improvements are evolutionary.

I bet the thing to do is to spend some time as one of the
elves who make bugzilla.kernel.org work smoothly despite
the software; then figure out what incremental tweak you
can make to the software to make the elves' and users' lives
better.

-- 
Dan Kegel
Linux User #78045
http://www.kegel.com

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.
> 
> Quoting Linus
> (http://marc.theaimsgroup.com/?l=linux-kernel&m=103911905214446&w=2):
> > And many things _can_ be done without throwing out old designs.
> > Implementation improvements are quite possible without trying to make
> > something totally new to the outside. ...
> > 
> > Not throwing out the baby with the bath-water doesn't mean that you cannot
> > improve the system. I'm only arguing against stupid people who think they
> > need a revolution to improve - most real improvements are evolutionary.

True, but there is always a point where you have to say, "This isn't
working, we need to re-write it".  Coding by cutting and pasting
existing code is not a great idea.

> I bet the thing to do is to spend some time as one of the
> elves who make bugzilla.kernel.org work smoothly despite
> the software; then figure out what incremental tweak you
> can make to the software to make the elves' and users' lives
> better.

I am not prepared to start editing the existing Bugzilla code - there
is nothing about it that I think it right at the moment.  I could
write a better bug tracking database in a couple of weeks if I wanted
to.

John.

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?
>>>
>>>I.E. I am prepared to write it myself, if people think it's
>>>worthwhile.
>>
>>Quoting Linus
>>(http://marc.theaimsgroup.com/?l=linux-kernel&m=103911905214446&w=2):
>>
>>>And many things _can_ be done without throwing out old designs.
>>>Implementation improvements are quite possible without trying to make
>>>something totally new to the outside. ...
>>>
>>>Not throwing out the baby with the bath-water doesn't mean that you cannot
>>>improve the system. I'm only arguing against stupid people who think they
>>>need a revolution to improve - most real improvements are evolutionary.
>>
> 
> True, but there is always a point where you have to say, "This isn't
> working, we need to re-write it".  Coding by cutting and pasting
> existing code is not a great idea.
> 
> 
>>I bet the thing to do is to spend some time as one of the
>>elves who make bugzilla.kernel.org work smoothly despite
>>the software; then figure out what incremental tweak you
>>can make to the software to make the elves' and users' lives
>>better.
> 
> 
> I am not prepared to start editing the existing Bugzilla code - there
> is nothing about it that I think it right at the moment.  I could
> write a better bug tracking database in a couple of weeks if I wanted
> to.

Ok, have you looked at other bug tracking programs?  Can you find 
something you can build on?  Take a look at this list of issue tracking 
software:
http://www.a-a-p.org/tools_tracking.html
It has a lot of possibilities... different combinations of features and 
implementation languages.

Could you perhaps expound a bit on your statement "there is nothing 
about [bugzilla] that I think [is] right at the moment"?

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]

> Ok, have you looked at other bug tracking programs?  Can you find 
> something you can build on?  Take a look at this list of issue tracking 
> software:
> http://www.a-a-p.org/tools_tracking.html
> It has a lot of possibilities... different combinations of features and 
> implementation languages.
> 
> Could you perhaps expound a bit on your statement "there is nothing 
> about [bugzilla] that I think [is] right at the moment"?

* It uses Javascript in the search forms
* The search forms are not intuitive to use
* It's difficult to check that you're not reporting a duplicate bug
* It's almost all only web-based
* There is no way that you can track different versions to the extent
  we need to.

The last point is the one that I think is most important.

Whenever somebody posts a bug report to LKML, quite often the first
thing somebody asks them is whether they have tried another kernel
version.  Most people don't have the time to try more than, say,
three different versions, and a lot of people might not want to use
the 2.5 development tree.

We _need_ a way to add data to a bug report like this:

* Original bug reporter reports a bug in 2.4.20.  It was also in
2.4.19

* Somebody else tries older versions, and discovers that it was
introduced in 2.4.15

* A third person discovers that recent 2.5 kernels are not affected,
because the code has been re-written.

Each time, information is added to the bug database _in a way that can
be easily searched_, not just as comments which cannot.

I don't know of an existing bug database system which can do that, or
is close to being able to do that.

John.

Re: Dedicated kernel bug database

[Eli Carter]

John Bradford wrote:
>>Ok, have you looked at other bug tracking programs?  Can you find 
>>something you can build on?  Take a look at this list of issue tracking 
>>software:
>>http://www.a-a-p.org/tools_tracking.html
>>It has a lot of possibilities... different combinations of features and 
>>implementation languages.
>>
>>Could you perhaps expound a bit on your statement "there is nothing 
>>about [bugzilla] that I think [is] right at the moment"?
> 
> 
> * It uses Javascript in the search forms
> * The search forms are not intuitive to use
> * It's difficult to check that you're not reporting a duplicate bug
> * It's almost all only web-based
> * There is no way that you can track different versions to the extent
>   we need to.
> 
> The last point is the one that I think is most important.
[snip explanation of version issue]

And what about GNATS?  What about the others on 
http://www.a-a-p.org/tools_tracking.html ?  A number of those address 
the web-based concern.  Do any of them answer your other concerns?  If 
there are, where do those fail that bugzilla, GNATS, etc. get it right?

But I see that starting from scratch is just the way you work: 
http://grabjohn.com/question.php?q=6

Well, have fun, good luck, and I do hope you come up with something 
useful and maintainable.

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]

> And what about GNATS?  What about the others on 
> http://www.a-a-p.org/tools_tracking.html ?  A number of those address 
> the web-based concern.  Do any of them answer your other concerns?  If 
> there are, where do those fail that bugzilla, GNATS, etc. get it right?

Why are you so against somebody sitting down and thinking, "OK, we
need a bug tracking database designed for debugging the Linux
kernel."?  I don't understand why you think it's a bad idea to start
over.  If my code was rubbish, then it wouldn't get used, and I wasted
my time.  Nobody else suffers.

> But I see that starting from scratch is just the way you work: 
> http://grabjohn.com/question.php?q=6

Well, since it's me that's offering to write the code, don't I get to
decide how to write it?

Besides, I'm not the only person who thinks it's a good idea to start
over sometimes - Eric Raymond even addresses this point in The
Cathedreal and the Bazaar.

http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html

> Well, have fun, good luck, and I do hope you come up with something 
> useful and maintainable.

If not, I will admit you were right to the list :-).

John.

Re: Dedicated kernel bug database

[Eli Carter]

John Bradford wrote:
>>And what about GNATS?  What about the others on 
>>http://www.a-a-p.org/tools_tracking.html ?  A number of those address 
>>the web-based concern.  Do any of them answer your other concerns?  If 
>>there are, where do those fail that bugzilla, GNATS, etc. get it right?
> 
> 
> Why are you so against somebody sitting down and thinking, "OK, we
> need a bug tracking database designed for debugging the Linux
> kernel."?  I don't understand why you think it's a bad idea to start
> over.  If my code was rubbish, then it wouldn't get used, and I wasted
> my time.  Nobody else suffers.

I'm not against someone starting over.  I'm against someone starting 
over without considering the existing base of code.  If for no other 
reason than to see what worked for others and what didn't.  A solid 
comparison of bugzilla, GNATS, and maybe a couple others with pros and 
cons for each can be extremely enlightening.... even if you decide none 
of them have a good, solid design.

My questions were an attempt to get at that comparison so that there was 
evidence that you knew the pitfalls of more than just bugzilla.  And I 
hoped that you might find another one that got some of those things right.

>>But I see that starting from scratch is just the way you work: 
>>http://grabjohn.com/question.php?q=6
> 
> Well, since it's me that's offering to write the code, don't I get to
> decide how to write it?

Absolutely!  I'm just trying to get you to step back from 'rewrite it!' 
as an initial assumption, and look at what already exists.  Maybe every 
wheel invented so far has 3 to 8 sides and we need to consider something 
other than a polygon.  Or maybe there is an oval out there that hints at 
a better way.  I'm just wanting to see that you have looked at more than 
the square wheel.

> Besides, I'm not the only person who thinks it's a good idea to start
> over sometimes - Eric Raymond even addresses this point in The
> Cathedreal and the Bazaar.
> 
> http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html
> 

Yes, but I didn't see much of an explanation of _why_ nothing out there 
was a good starting point.  Nor did I see an indication that you had 
gone and looked at more than just bugzilla.

>>Well, have fun, good luck, and I do hope you come up with something 
>>useful and maintainable.
> 
> 
> If not, I will admit you were right to the list :-).

*chuckle*  I think you are _premature_ in saying "rewrite!", not _wrong_ 
in saying "rewrite!"  And I will by no means tell you to sit and twiddle 
your thumbs instead of writing something, even if I think that something 
already exists in perfect form.  (Which in this case, I don't. :) )

Have fun!

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

[Horst von Brand]

John Bradford <john@grabjohn.com> said:
> > And what about GNATS?  What about the others on 
> > http://www.a-a-p.org/tools_tracking.html ?  A number of those address 
> > the web-based concern.  Do any of them answer your other concerns?  If 
> > there are, where do those fail that bugzilla, GNATS, etc. get it right?
> 
> Why are you so against somebody sitting down and thinking, "OK, we
> need a bug tracking database designed for debugging the Linux
> kernel."?

I didn't see anybody saying that...

>           I don't understand why you think it's a bad idea to start
> over.  If my code was rubbish, then it wouldn't get used, and I wasted
> my time.  Nobody else suffers.

Except for the users who tried it out, and the people who read the ensuing
flamewars ;-)

"Start over" is one thing, "start over as if nothing had been done before"
is another (and a bad idea, whatever you are trying to do).

Linux has borrowed much from Unix, in design and also in avoiding mistakes
made elsewhere. Do follow this example.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Dedicated kernel bug database

[Dan Kegel]

Eli Carter wrote:
> But I see that starting from scratch is just the way you work: 
> http://grabjohn.com/question.php?q=6

Ah, he must have sipped the same kool-aid as djb :-)

That works only as long as you're incredibly talented,
and don't mind being a loner.
- Dan

-- 
Dan Kegel
Linux User #78045
http://www.kegel.com

Re: Dedicated kernel bug database

[Dan Kegel]

Eli Carter wrote:
> But I see that starting from scratch is just the way you work: 
> http://grabjohn.com/question.php?q=6

It gets worse:
http://grabjohn.com/question.php?q=9

-- 
Dan Kegel
Linux User #78045
http://www.kegel.com

Re: Dedicated kernel bug database

[John Bradford]

> > But I see that starting from scratch is just the way you work: 
> > http://grabjohn.com/question.php?q=6
> 
> It gets worse:
> http://grabjohn.com/question.php?q=9

It gets worse still:

http://grabjohn.com/question.php?q=7

Do I have the only web page in the world that rejects the world's most
popular web browser?

http://grabjohn.com/fruit2.php

John.

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

[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

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

[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

[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

[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

[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

[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

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

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

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

[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

[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

[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

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

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

[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

[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, 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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

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

[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

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

[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

[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

[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

[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

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