Following on from yesterday's discussion about there not being much
interaction between the kernel Bugzilla and the developers, I began
wondering whether Bugzilla might be a bit too generic to be suited to
kernel development, and that maybe a system written from the ground up
for reporting kernel bugs would be better?
I.E. I am prepared to write it myself, if people think it's
worthwhile.
For example, we get a lot of posts on LKML like this:
"Hi, foobar doesn't work in 2.4.19"
Now, does that mean:
* The bug first appeared in 2.4.19, and is still in 2.4.20
* The bug reporter hasn't tested 2.4.20
* The bug reporter can't test 2.4.20 because something else is broken
* The bug actually first appeared in 2.4.10, but it didn't irritate
them enough to complain until now.
A bug database designed from scratch could allow such information to
be indexed in a way that could be processed and searched usefully. A
list of tick-boxes for worked/didn't work/didn't test/couldn't test
for several kernel versions could be presented.
Also, we could have a non-web interface, (telnet or gopher to the bug
DB, or control it by E-Mail).
It could warn the user if they attach an un-decoded oops that their
bug report isn't as useful as it could be, and if they mention a
distribution kernel version, that it's not a tree that the developers
will necessarily be familiar with.
I'm not criticising the fact that we've got Bugzilla up and running,
but just pointing out that we could do better, (and I'm prepared to
put in the time and effort). I just need ideas, really.
John.
I would just like to second what somebody said about bugzilla yesterday,
that it is hard to search for bugs that have already been entered. Just
something to think about.
--Brian Jackson
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
John Bradford <[email protected]> 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
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 `-------------------------------------------------
> > 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.
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 `-------------------------------------------------
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
> > >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.
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 `-------------------------------------------------
> 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.
[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.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
> > 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.
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 `-------------------------------------------------
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
[email protected] (or at least have [email protected] 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
> > > 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.
> > 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.
[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
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 `-------------------------------------------------
> 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.
>
> > > 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/
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 `-------------------------------------------------
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
> >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.
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
> | > 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.
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
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
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 `-------------------------------------------------
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
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? :)
> 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
> > 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.
> 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
--On Thursday, December 19, 2002 06:59:30 PM -0500 Pete Zaitcev <[email protected]> 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)
> Date: Thu, 19 Dec 2002 16:19:03 -0800
> From: Hanna Linder <[email protected]>
> >> 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
--On Thursday, December 19, 2002 07:24:19 PM -0500 Pete Zaitcev <[email protected]> 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
>> 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.
--On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <[email protected]> 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
--On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <[email protected]> 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
Hanna Linder wrote:
> --On Thursday, December 19, 2002 06:59:30 PM -0500 Pete Zaitcev <[email protected]> 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
>> 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 are a bunch of categories that aren't really "owned" as such,
>> and default to khoa or myself. Those are really good candidates to
>> steal ... they'll be owned by bugme-janitors soon to make this more
>> obvious ...
>
> OK. Which categories are not owned? Anything with you or khoa as owners?
More or less, yes. There are a couple of categories I really own, eg
NUMA/discontigmem, and I'll probably look after ia32 specific bugs
unless Linus wants his category back ;-)
Will switch to bugme-janitors in a few days, then will all be much more
obvious
M.
On Thu, 19 Dec 2002, Martin J. Bligh wrote:
| >> There are a bunch of categories that aren't really "owned" as such,
| >> and default to khoa or myself. Those are really good candidates to
| >> steal ... they'll be owned by bugme-janitors soon to make this more
| >> obvious ...
| >
| > OK. Which categories are not owned? Anything with you or khoa as owners?
|
| More or less, yes. There are a couple of categories I really own, eg
| NUMA/discontigmem, and I'll probably look after ia32 specific bugs
| unless Linus wants his category back ;-)
|
| Will switch to bugme-janitors in a few days, then will all be much more
| obvious
What does this last sentence mean?
--
~Randy
> 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.
>| >> 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
> 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.
> 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.
[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.
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
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
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
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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|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
John Bradford <[email protected]> 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
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
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 `-------------------------------------------------
> 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.
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
--On Friday, December 20, 2002 10:35:27 AM +0000 Dave Jones <[email protected]> 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
--On Friday, December 20, 2002 09:09:31 AM -0600 Jon Tollefson <[email protected]> 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
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 <[email protected]> wrote:
> --On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <[email protected]> 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
>
>
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 <[email protected]> wrote:
>
> > --On Thursday, December 19, 2002 05:39:56 PM -0800 "Martin J. Bligh" <[email protected]> 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
On Fri, 2002-12-20 at 17:52, Hanna Linder wrote:
> --On Friday, December 20, 2002 09:09:31 AM -0600 Jon Tollefson <[email protected]> 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
What are your ideas???
Regards, Dean.
On Fri, 20 Dec 2002 09:48:53 +0000 (GMT) John Bradford <[email protected]> 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.
> 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.
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
[email protected] \ / 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."
--On Friday, December 20, 2002 09:27:24 PM -0600 Jon Tollefson <[email protected]> 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" <[email protected]> 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