I would like to ask everyone NOT to use bugme.osdl.org
for networking bug reporting any more.
It's absolutely the wrong model. When a bug gets filed that way
it sort of goes into a black hole that _I_ am forced to process,
forward, etc. the bug around and I don't want to be forced to do
mindless work like that when it is totally unnecessary.
I want people to post the bug to linux-net and netdev and discuss
the problem there. And that solves all of the problems.
Thanks a lot.
> I would like to ask everyone NOT to use bugme.osdl.org
> for networking bug reporting any more.
>
> It's absolutely the wrong model. When a bug gets filed that way
> it sort of goes into a black hole that _I_ am forced to process,
> forward, etc. the bug around and I don't want to be forced to do
> mindless work like that when it is totally unnecessary.
>
> I want people to post the bug to linux-net and netdev and discuss
> the problem there. And that solves all of the problems.
>
> Thanks a lot.
I'll take you off the maintainers list, and find someone else to do
it for networking. If you want net bugs reported to mailing lists,
that's fine.
If people choose to file bugs in bugzilla as well, they'll still be
processed by someone.
M.
From: "Martin J. Bligh" <[email protected]>
Date: Thu, 26 Jun 2003 22:46:10 -0700
If people choose to file bugs in bugzilla as well, they'll still be
processed by someone.
Just so that someone can post them to the lists?
That sounds like a completely silly way to operate.
I'd rather they get posted to the lists _ONLY_.
This way not that "someone", but "everyone" on the lists
can participate and contribute to responding to the bug.
The only way you can make things scale is if you throw a group
of people into the collective of folks able to respond to a problem.
If it all gets filtered through by one guy, THAT DOES NOT WORK.
That one guy limits what can be done, and when he's busy one day
or he goes away on vacation for a while, the whole assembly
line stops.
Therefore, please eliminate the networking category on bugme.osdl.org
and we'll process bug reports on the lists so that not _ONE_ but the
whole community of networking developers can look at the bug.
On Thu, Jun 26, 2003 at 10:47:39PM -0700, David S. Miller wrote:
> From: "Martin J. Bligh" <[email protected]>
> Date: Thu, 26 Jun 2003 22:46:10 -0700
>
> If people choose to file bugs in bugzilla as well, they'll still be
> processed by someone.
>
> Just so that someone can post them to the lists?
> That sounds like a completely silly way to operate.
>
> I'd rather they get posted to the lists _ONLY_.
I have recently pondered usage of Request Tracker for this
kind of tasks. The problem with "post to the list" is that
sometimes things slip thru without anybody catching them.
Integrating linux-kernel and RT ... urgh.. result would
be quite ugly. (Flame wars and out-of-topic threads going on
as requests...)
> This way not that "someone", but "everyone" on the lists
> can participate and contribute to responding to the bug.
That needs merely message arriving to the list.
Ok, responding so that the response appears also
at the bug db is another story.
> The only way you can make things scale is if you throw a group
> of people into the collective of folks able to respond to a problem.
>
> If it all gets filtered through by one guy, THAT DOES NOT WORK.
> That one guy limits what can be done, and when he's busy one day
> or he goes away on vacation for a while, the whole assembly
> line stops.
Bugzilla could be adapted to this use:
- Bugs are to be assigned to, e.g. linux-net/netdev list
- Everybody can comment on them at bugme (after signing on)
- Only some meta-admin (and original bug creator) can
alter status (e.g. mark as RESOLVED)
Having plenty of bugme group admins (half a dozen or so) to do
the initial bugzilla assigment work, those people taking the task
seriously, and everybody of them going en masse to assign arrived
things. That way people can have time off - as long as they
coordinate among themselves.
The minus (and plus) is, of course, that the entire discussion
flowing at the list doesn't go to the bug database, but that
doesn't invalidate mechanisms existence as a way to avoid
slipping things thru the cracks.
> Therefore, please eliminate the networking category on bugme.osdl.org
> and we'll process bug reports on the lists so that not _ONE_ but the
> whole community of networking developers can look at the bug.
I thought you don't need to login to see things in bugzilla ?
.. and proved it by looking into bugme..
http://bugme.osdl.org/show_bug.cgi?id=853
In addition to assinging an OWNER to the bug, there should be
automatic assignment of linux-net or netdev as Cc, IMO...
That will handle the "publish widely" issue that DaveM is
complaining about.
/Matti Aarnio
From: Matti Aarnio <[email protected]>
Date: Fri, 27 Jun 2003 10:59:14 +0300
The problem with "post to the list" is that sometimes things slip
thru without anybody catching them.
It is not a problem, it is a feature. What will happen is the
same thing that happens if Linus drops a patch.
It'll get retransmitted if the reporter cares about the
bug. If he doesn't, the one of two things:
1) the bug actually isn't that important
2) it is important, and someone else will report the bug too
Therefore important issues tend to keep showing up, even if
they are not attended to the first time around. This repeated
reporting and patch sending may seem like useless work, but this
is not true, it is actually a form of validation.
I thought you don't need to login to see things in bugzilla ?
That's not the issue. Asking people who want to help to
read a list or two, isn't much to ask. Getting them to click
around some web site every day adds to the overhead.
> If people choose to file bugs in bugzilla as well, they'll still be
> processed by someone.
>
> Just so that someone can post them to the lists?
> That sounds like a completely silly way to operate.
>
> I'd rather they get posted to the lists _ONLY_.
>
> This way not that "someone", but "everyone" on the lists
> can participate and contribute to responding to the bug.
>
> The only way you can make things scale is if you throw a group
> of people into the collective of folks able to respond to a problem.
We can do that. The owner of a category can be a mailing list
(eg the bugme-janitors list for some of the categories).
> If it all gets filtered through by one guy, THAT DOES NOT WORK.
> That one guy limits what can be done, and when he's busy one day
> or he goes away on vacation for a while, the whole assembly
> line stops.
The idea is to spread it across categories (one person for each (or a few)
categories), but if you want to spread it around within a category that's
possible too.
> Therefore, please eliminate the networking category on bugme.osdl.org
> and we'll process bug reports on the lists so that not _ONE_ but the
> whole community of networking developers can look at the bug.
No. If you don't want to participate, that's fine, but I'm not going
to prevent other people from doing so.
If you want me to forward the bugs to any given list, I'll do that.
If you want to just tell people to file them to a list, that's fine too.
But I won't destroy the generic model just because you don't like it.
M.
On Fri, 27 Jun 2003, Martin J. Bligh wrote:
> No. If you don't want to participate, that's fine, but I'm not going
> to prevent other people from doing so.
>
> If you want me to forward the bugs to any given list, I'll do that.
> If you want to just tell people to file them to a list, that's fine too.
> But I won't destroy the generic model just because you don't like it.
A bug tracking system stick you on a bug and makes all this to look like
real work, that's why maybe David does not like it :) Kidding ;) The good
of a bug tracking system against the mailing list is that bugs do survive
in a bug tracking system, while they usually vanish for normal underlooked
posts. Many ppl posting bugs are not members of the mailing list and they
are not usually setting up a repost timer if the bug does not get
answered. I believe that it should be both ways. Posts on the mailing list
helps main maintainers to lower the load by allowing others to take on
bugs, while the bug tracking helps unresolved bugs to stick.
- Davide
> I have recently pondered usage of Request Tracker for this
> kind of tasks. The problem with "post to the list" is that
> sometimes things slip thru without anybody catching them.
>
> Integrating linux-kernel and RT ... urgh.. result would
> be quite ugly. (Flame wars and out-of-topic threads going on
> as requests...)
Yeah, that is tricky ... see below.
>> This way not that "someone", but "everyone" on the lists
>> can participate and contribute to responding to the bug.
>
> That needs merely message arriving to the list.
That's easy. I actually already hand filter the bugs, and forward to
linux-kernel those that seem to have enough information in to be useful
to people, and aren't already fixed.
There's also a mailing list for seeing every new bug that people can
sign up for if they want (send me private email).
> Ok, responding so that the response appears also
> at the bug db is another story.
That is possible to do - there's patches to Bugzilla that implement an
email interface, but it has some problems like the one you pointed out
above. One possiblility is to make people manually do something to the
email for each reply, but that's rather ugly.
Hopefully we can discuss this more at OLS this year, and get a plan
going forward that people are happy with. I'm well aware that Bugzilla
is not the perefect tool, but I think it's better than what we had
before (yeah, I know some of us disagree), and is easy to change.
I'd rather start with something simple, and evolve it to the needs of
the community than try dumping something complex onto people up front.
> Bugzilla could be adapted to this use:
> - Bugs are to be assigned to, e.g. linux-net/netdev list
> - Everybody can comment on them at bugme (after signing on)
> - Only some meta-admin (and original bug creator) can
> alter status (e.g. mark as RESOLVED)
>
> Having plenty of bugme group admins (half a dozen or so) to do
> the initial bugzilla assigment work, those people taking the task
> seriously, and everybody of them going en masse to assign arrived
> things. That way people can have time off - as long as they
> coordinate among themselves.
Yup, that's easy to set up if you like. Or we can do it as a new list
if you prefer.
> In addition to assinging an OWNER to the bug, there should be
> automatic assignment of linux-net or netdev as Cc, IMO...
> That will handle the "publish widely" issue that DaveM is
> complaining about.
There's a QA field we can hack into doing that easily, but I want to
ensure people are happy auto-cc'ing lists before I do it. Or I can
forward the relevant ones by hand if you prefer. If it's going to piss
people off more than it makes them happy, it's not worth it though.
Moreover, the bugme default owner doesn't have to be the code maintainer,
so if Dave wants someone else to do the "bug shuffling" stuff, that's
another way to go.
M.
> > Ok, responding so that the response appears also
> > at the bug db is another story.
>
> That is possible to do - there's patches to Bugzilla that implement an
> email interface, but it has some problems like the one you pointed out
> above. One possiblility is to make people manually do something to the
> email for each reply, but that's rather ugly.
>
> Hopefully we can discuss this more at OLS this year, and get a plan
> going forward that people are happy with. I'm well aware that Bugzilla
> is not the perefect tool, but I think it's better than what we had
> before (yeah, I know some of us disagree), and is easy to change.
> I'd rather start with something simple, and evolve it to the needs of
> the community than try dumping something complex onto people up front.
I did make the effort to make a dedicated bug database for kernel
development in December last year. Do people actively hate it, or are
they just not aware of it? :-). I got some very favourable comments
early on, and a review in a Linux magazine, but haven't had much
feedback recently about it. I was specifically trying to address the
kind of problems we're seeing with Bugzilla...
http://grabjohn.com/kernelbugdatabase
John.
Hi,
Some people have already written part of what I'll say but I'll give a
quick POV anyway.
1. a single centralised database is *good*. This allows bugs to be
reassigned at need without loosing history (eg networking does not work
and investigation reveals its because of broken irq routing...). The
easiest way right now to kill a report is to ask to move it to another
mailing list.
2. bugs are never lost/ignored. They might move from maintainer to
maintainer but at least no one can feel "it involves x y z - I maintain
x but y or z maintainer are better suited to handle it, let them do it"
3. single human point-of-failure is a false problem - using a mailing
list as default assignee can help spread the load (one could say this
negates 2. but a small group of QA can insure no bug is left sleeping
overlong)
4. bugzilla is well known - it might have its warts but they are less
annoying for the average user that to have to learn rt... interface.
Regards,
--
Nicolas Mailhot
David S. Miller wrote:
> From: "Martin J. Bligh" <[email protected]>
> Date: Thu, 26 Jun 2003 22:46:10 -0700
>
> If people choose to file bugs in bugzilla as well, they'll still be
> processed by someone.
>
> Just so that someone can post them to the lists?
> That sounds like a completely silly way to operate.
>
> I'd rather they get posted to the lists _ONLY_.
I'm sure bugz could be set up to send a report to netdev everytime
a bug was entered. And, we would also have a good record of bugs
that people could search. It would also keep bugs from falling through
the cracks: If 'everyone' is responsible, that can often mean that
no one takes responsibility.
Ben
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
From: Davide Libenzi <[email protected]>
Date: Fri, 27 Jun 2003 07:56:16 -0700 (PDT)
The good of a bug tracking system against the mailing list is that
bugs do survive in a bug tracking system,
No, this is the _BAD_ part, shit accumulates equally with
useful reports.
Useful reports in non-bugtracking system environments get
retransmitted and eventually looked at.
From: Ben Greear <[email protected]>
Date: Fri, 27 Jun 2003 11:50:43 -0700
It would also keep bugs from falling through the cracks:
People DON'T understand. I _WANT_ them to be able to
fall through the cracks.
If it's important, people will retransmit.
This work for kernel patches, and has so for over 5 years.
So what makes anyone thing it doesn't work for bug reporting?
David S. Miller wrote:
> From: Davide Libenzi <[email protected]>
> Date: Fri, 27 Jun 2003 07:56:16 -0700 (PDT)
>
> The good of a bug tracking system against the mailing list is that
> bugs do survive in a bug tracking system,
>
> No, this is the _BAD_ part, shit accumulates equally with
> useful reports.
>
> Useful reports in non-bugtracking system environments get
> retransmitted and eventually looked at.
I think you are putting too much work on the bug reporter(s). If
you want to ignore bug reports that only happen once, feel free,
but give the rest of us a way to easily keep a history and list
of bug reports.
For instance, where is the list of open networking bugs for
2.4 now?
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
From: Ben Greear <[email protected]>
Date: Fri, 27 Jun 2003 14:54:26 -0700
I think you are putting too much work on the bug reporter(s).
Don't even talk to me about too much work.
Someone wants me to spend hours groveling through some pieces of code
to track down some tricky bug, for free, and all I ask is that they
retransmit the bug every once in a while if they don't see any
response?
Give me a frigging break.
If they're not willing to do this, they DON'T care about the bug.
Just like if people aren't willing to retransmit patches they want
installed, they DON'T care about the patch. And just like I don't
want to apply patches people don't care about, I don't want any of my
contributors looking at bugs that the bug reporter doesn't care about.
Just like with patches, I want to know that people are going to stick
around and be responsive if I need to get information from them when
a bug is reported. If they're not willing to retransmit the report
every one in a while, why should I believe they will?
Ben, you absolutely don't understand how all of this development works
and what it relies upon to function properly.
On Fri, 27 Jun 2003, David S. Miller wrote:
> No, this is the _BAD_ part, shit accumulates equally with
> useful reports.
>
> Useful reports in non-bugtracking system environments get
> retransmitted and eventually looked at.
David, your method is the dream of every software developer. Having Q/A
repeatedly pushing the same issue. Having a track is good and flagging a
report as not-a-bug or need-more-info takes almost the same time (if the
system is sanely designed) it takes you to flag your message a shit. In
this way though you do not lose things meaningful that you overlooked at
first sight. And this comes from someone that wanted to quit his job when
they forced for the first time to use a tracking system ;)
- Davide
From: Davide Libenzi <[email protected]>
Date: Fri, 27 Jun 2003 15:02:00 -0700 (PDT)
David, your method is the dream of every software developer.
It is not a dream, it works perfectly fine and has done so
for 5+ years of Linux maintainence.
To make these things scale you MUST push the work out to other people,
you absolutely cannot centralize. And here we're pushing it out to
the bug reporters, just like we push the work of patch maintainence to
the patch submitters.
If they don't care about the bug and won't retransmit when their
stuff isn't being looked at, their bug isn't worth being looked
at.
I know that's a hard pill to swallow, but over years of work I can
tell you this is the only scalable mechanism. Nobody likes this
because it's not tracked somewhere and they can't show some pretty
list of bugs to their management at the end of each week, TOO FUCKING
BAD. Pay someone to work on your bugs if you want a pretty list and
people being REQUIRED to look at and fix bugs. None of this crap is
my problem.
On Fri, 27 Jun 2003, David S. Miller wrote:
> From: Davide Libenzi <[email protected]>
> Date: Fri, 27 Jun 2003 15:02:00 -0700 (PDT)
>
> David, your method is the dream of every software developer.
>
> It is not a dream, it works perfectly fine and has done so
> for 5+ years of Linux maintainence.
>
> To make these things scale you MUST push the work out to other people,
> you absolutely cannot centralize. And here we're pushing it out to
> the bug reporters, just like we push the work of patch maintainence to
> the patch submitters.
>
> If they don't care about the bug and won't retransmit when their
> stuff isn't being looked at, their bug isn't worth being looked
> at.
David, I'm not willing to waste both precious time arguing on this but I
will leave you question to think about. Is a bug report more useful for
the user of a "system" or for the "system" itself ?
- Davide
David S. Miller wrote:
> From: Ben Greear <[email protected]>
> Date: Fri, 27 Jun 2003 14:54:26 -0700
>
> I think you are putting too much work on the bug reporter(s).
>
> Don't even talk to me about too much work.
>
> Someone wants me to spend hours groveling through some pieces of code
> to track down some tricky bug, for free, and all I ask is that they
> retransmit the bug every once in a while if they don't see any
> response?
I don't care if you completely ignore the bugzilla, just let the
rest of us lesser mortals use it. There's always the chance we
will find something we can fix and actually lessen your load.
> If they're not willing to do this, they DON'T care about the bug.
> Just like if people aren't willing to retransmit patches they want
> installed, they DON'T care about the patch. And just like I don't
> want to apply patches people don't care about, I don't want any of my
> contributors looking at bugs that the bug reporter doesn't care about.
Forcing people to continue to retransmit the same report just pisses
people off, and in the end will get you less useful reports than if
you had flagged the report as 'please-gimme-more-info'. And, most people,
especially the savvy ones, will find some sort of work-around and keep going.
That didn't fix the problem, it just made it invisible again untill the
next person hits it.
> Ben, you absolutely don't understand how all of this development works
> and what it relies upon to function properly.
Perhaps, but it's also possible that you are being a stubborn SOB
because you fear change :)
Ben
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
From: Davide Libenzi <[email protected]>
Date: Fri, 27 Jun 2003 15:11:53 -0700 (PDT)
Is a bug report more useful for the user of a "system" or for the
"system" itself ?
You can ask the same question about a patch, and my answer
is the same, "it depends upon the bug/patch and whether
the people it affects actually care about it".
What's truly "useful" for the "system" are things that allow
the people that maintain it to SCALE. Lossless bug and patch
databases that force me to look at each and every item do not scale.
What you don't understand is that I, and most of the people who help
me, do this because I and they want to. So as soon as things get
introduced that make us less "want" to do this you can be sure
contributions will slump slowly but surely to nothing.
From: Ben Greear <[email protected]>
Date: Fri, 27 Jun 2003 15:15:07 -0700
Forcing people to continue to retransmit the same report just pisses
people off, and in the end will get you less useful reports than if
you had flagged the report as 'please-gimme-more-info'.
And this is different from patch submission in what way?
Perhaps, but it's also possible that you are being a stubborn SOB
because you fear change :)
Absolutely not, in fact I'm daily looking for ways to change how
I work with people who help me so that I scale better. And I know
for sure that a bug datamase with shit that accumulates in it
that _REQUIRES_ me to do something about it to make it go away
does not help me scale.
Bugme was an absolute burdon for me.
For something to scale, it must continute to operate just as
efficiently if I were to go away for a few weeks. The lists have that
quality, the bug database with owner does not.
David S. Miller wrote:
> From: Ben Greear <[email protected]>
> Date: Fri, 27 Jun 2003 15:15:07 -0700
>
> Forcing people to continue to retransmit the same report just pisses
> people off, and in the end will get you less useful reports than if
> you had flagged the report as 'please-gimme-more-info'.
>
> And this is different from patch submission in what way?
It wouldn't bother me to have a list of all patches submitted either,
it would keep folks from re-implementing the same thing from time to
time. However, the main difference is that having to cary patches
forward is a constant drag on the person with the patch that was not
accepted, so they are constantly aware of how nice it would be to
get it included..thus they may keep trying.
A user with a PCMCIA NIC that reorders packets can get another NIC, so
that bug will never re-transmitted, and it will never get fixed. What
is worse, new users of that busted NIC will have to re-discover that all
over for themselves, because there is no bug database to search.
>
> Perhaps, but it's also possible that you are being a stubborn SOB
> because you fear change :)
>
> Absolutely not, in fact I'm daily looking for ways to change how
> I work with people who help me so that I scale better. And I know
> for sure that a bug datamase with shit that accumulates in it
> that _REQUIRES_ me to do something about it to make it go away
> does not help me scale.
>
> Bugme was an absolute burdon for me.
>
> For something to scale, it must continute to operate just as
> efficiently if I were to go away for a few weeks. The lists have that
> quality, the bug database with owner does not.
So, you'd be happy so long as bugz sent mail to the netdev mailing lists
instead of to you?
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
On Fri, Jun 27, 2003 at 03:02:00PM -0700, Davide Libenzi wrote:
> On Fri, 27 Jun 2003, David S. Miller wrote:
>
> > No, this is the _BAD_ part, shit accumulates equally with
> > useful reports.
> >
> > Useful reports in non-bugtracking system environments get
> > retransmitted and eventually looked at.
>
> David, your method is the dream of every software developer. Having Q/A
> repeatedly pushing the same issue. Having a track is good and flagging a
> report as not-a-bug or need-more-info takes almost the same time (if the
> system is sanely designed) it takes you to flag your message a shit. In
> this way though you do not lose things meaningful that you overlooked at
> first sight. And this comes from someone that wanted to quit his job when
> they forced for the first time to use a tracking system ;)
As a bug reporter, and as someone who receives bug reports, I can say
that on both ends I find it easier to send emails, and get emails than
to fiddle with any bug tracking tool.
I'm with Dave on this one. Scrap the nifty tools, and just use good
sense. Emails let each developer handle bug reports in their own way.
I'm sure you could make a nice local tool for yourself to manage your
own bug reports.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
--"David S. Miller" <[email protected]> wrote (on Friday, June 27, 2003 14:44:26 -0700):
> From: Ben Greear <[email protected]>
> Date: Fri, 27 Jun 2003 11:50:43 -0700
>
> It would also keep bugs from falling through the cracks:
>
> People DON'T understand. I _WANT_ them to be able to
> fall through the cracks.
I fail to see your point here. If that's what you want, then just don't
look at the bugme data. However it's still available for other people
that do want to see it.
I can easily arrange for them to be transmitted when first filed by email,
in fact we already do that.
M.
On Fri, Jun 27, 2003 at 03:47:22PM -0700, Martin J. Bligh wrote:
> --"David S. Miller" <[email protected]> wrote (on Friday, June 27, 2003 14:44:26 -0700):
>
> > From: Ben Greear <[email protected]>
> > Date: Fri, 27 Jun 2003 11:50:43 -0700
> >
> > It would also keep bugs from falling through the cracks:
> >
> > People DON'T understand. I _WANT_ them to be able to
> > fall through the cracks.
>
> I fail to see your point here.
This might help. Or not.
Brain dump on the bug tracking problem from the Kernel Summit discussions
[SCCS/s.BUGS vers 1.3 2001/04/05 13:10:10]
Outline
Problems
Problem details
Past experiences
Requirements
Problems
- getting quality bug reports
- not losing any bugs
- sorting low signal vs high signal into a smaller high signal pile
- simplified, preferably NNTP, access to the bug database (Linus
would use this; he's unlikely to use anything else)
Problem details
Bug report quality
There was lots of discussion on this. The main agreement was that we
wanted the bug reporting system to dig out as much info as possible
and prefill that. There was a lot of discussion about possible tools
that would dig out the /proc/pci info; there was discussion about
Andre's tools which can tell you if you can write your disk; someone
else had something similar.
But the main thing was to extract all the info we could
automatically. One thing was the machine config (hardware and
at least kernel version). The other thing was extract any oops
messages and get a stack traceback.
The other main thing was to define some sort of structure to the
bug report and try and get the use to categorize if they could.
In an ideal world, we would use the maintainers file and the
stack traceback to cc the bug to the maintainer. I think we want
to explore this a bit. I'm not sure that the maintainer file is
the way to go, what if we divided it up into much broader chunks
like "fs", "vm", "network drivers", and had a mail forwarder
for each area. That could fan out to the maintainers.
Not losing bugs
While there was much discussion about how to get rid of bad,
incorrect, and/or duplicate bug reports, several people - Alan
in particular - made the point that having a complete collection
of all bug reports was important. You can do data mining across
all/part of them and look for patterns. The point was that there
is some useful signal amongst all the noise so we do not want to
lose that signal.
Signal/noise
We had a lot of discussion about how to deal with signal/noise.
The bugzilla proponents thought we could do this with some additional
hacking to bugzilla. I, given the BitKeeper background, thought
that we could do this by having two databases, one with all the
crud in it and another with just the screened bugs in it. No matter
how it is done, there needs to be some way to both keep a full list,
which will likely be used only for data mining, and another, much
smaller list of screened bugs. Jens wants there to be a queue of
new bugs and a mechanism where people can come in the morning, pull
a pile of bugs off of the queue, sort them, sending some to the real
database. This idea has a lot of merit, it needs some pondering as
DaveM would say, to get to the point that we have a workable mechanism
which works in a distributed fashion.
The other key point seemed to be that if nobody picked up a bug and
nobody said that this bug should be picked up, then the bug expires
out of the pending queue. It gets stashed in the bug archive for
mining purposes and it can be resurrected if it later becomes a real
bug, but the key point seems to be that it _automatically_ disappears
out of the pending queue. I personally am very supportive of this
model. We need some way to just let junk stay junk. If junk has to
be pruned out of the system by humans, the system sucks. The system,
not humans, needs to autoprune.
Simplified access: browsing and updating
Linus made the point that mailing lists suck. He isn't on any and
refuses to join any. He reads lists with a news reader. I think
people should sit up and listen to that - it's a key point. If your
mailing list isn't gatewayed to a newsgroup, he isn't reading it and
a lot of other people aren't either.
There was a fair bit of discussion about how to get the bug database
connected to news. There doesn't seem to be any reason that the
bug system couldn't be a news server/gateway. You should be able to
browse
bitbucket.kernel.bugs - all the unscreened crud
screened.kernel.bugs - all bugs which have been screened
fs.kernel.bugs - screened bugs in the "fs" category
ext2.kernel.bugs - screened bugs in the "ext2" category
eepro.kernel.bugs - screened bugs in the "eepro" category
etc.
Furthermore, the bugs should be structured once they are screened,
i.e., they have a set of fields like (this is a strawman):
Synopsis - one line man-page like summary of the bug
Severity - how critical is this bug?
Priority - how soon does it need to be fixed?
Category - subsystem in which the bug occurs
Description - details on the bug, oops, stack trace, etc.
Hardware - hardware info
Software - kernel version, glibc version, etc.
Suggested fix - any suggestion on how to fix it
Interest list - set of email addresses and/or newsgroups for updates
It ought to work that if someone posts a followup to the bug then if
the followup changes any of the fields that gets propagated to the
underlying bug database. If this is done properly the news reader will
be the only interface that most people use.
Past experiences
This is a catch all for sound bytes that we don't want to forget...
- Sorting bugs by hand is a pain in the ass (Ted burned out on it and
Alan refuses to say that it is the joy of his life to do it)
- bug systems tend to "get in the way". Unless they are really trivial
to submit, search, update then people get tired of using them and go
back to the old way
- one key observation: let bugs "expire" much like news expires. If
nobody has been whining enough that it gets into the high signal
bug db then it probably isn't real. We really want a way where no
activity means let it expire.
- Alan pointed out that having all of the bugs someplace is useful,
you can search through the 200 similar bugs and notice that SMP
is the common feature.
Requirements
This section is mostly empty, it's here as a catch all for people's
bullet items.
- it would be very nice to be able to cross reference bugs to bug fixes
in the source management system, as well as the other way around.
- mail based interface
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Gwe, 2003-06-27 at 22:44, David S. Miller wrote:
> This work for kernel patches, and has so for over 5 years.
> So what makes anyone thing it doesn't work for bug reporting?
It works badly for kernel patches, stuff does get lost forever, missed
etc. Having it all archived somewhere is really valuable because it
means you can spot patterns, trends and also when someone who isnt a
hacker hits the bug *they* can find the patch you missed and send it on
or remind you
You are assuming there is a relationship in bug severity/commonness and
number of *developers* who hit it. That isnt true, developer and end
user hardware patterns are radically different in some areas
On Gwe, 2003-06-27 at 23:19, David S. Miller wrote:
> Forcing people to continue to retransmit the same report just pisses
> people off, and in the end will get you less useful reports than if
> you had flagged the report as 'please-gimme-more-info'.
>
> And this is different from patch submission in what way?
Tried doing an SQL query or text analysis for similarities on random
messages lurking in private mailboxes or mixed up in list archives.
Its really hard.
Now try doing that with bugzilla and its really easy. Nobody is saying
"Dave shall use bugzilla", maybe you can find an underling to care,
maybe the only time you want to use it is to say "thats really freaky,
who else is seeing it and what hardware"
>From Red Hat bugzilla I've done statistical analysis of IDE failure
patterns, I've also dug up year old mislaid patches that would have
been lost forever otherwise because the one person who fixed it was
missed in the noise, even though lots of the noise was people hitting
that same bug
Ben Collins <[email protected]> wrote:
>
> I'm with Dave on this one.
I also. The bug database tries to convert the traditional many<->many
debugging process into a one<->one process. This surely results in a
lower cleanup rate.
It's irritating replying to a bugzilla entry when you _know_ that you're
cutting other interested parties out of the loop.
And mailing lists tend to be self-correcting:
- The once-off bugs due to broken hardware get filtered away.
- The bugs which simply get magically fixed when someone repaired some
unrelated part of the kernel get filtered out.
- The bugs which are affecting people the most get reported the most.
- Lots of other people can chip in with potentially useful info.
It is nice to have a record. But bugzilla is not a comfortable or
productive environment within which to drill down into and fix problems.
> - The bugs which are affecting people the most get reported the most.
Not to mention the "breeding" affect. A bug that many people have seen
only once, but can never pinpoint because they can't reproduce it. One
of those people reports the problem to the mailing list, and suddenly
half a dozen respond with "me too, but here's some extra info that I
saw". You can't get that with a bug database.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
From: Ben Greear <[email protected]>
Date: Fri, 27 Jun 2003 15:36:30 -0700
So, you'd be happy so long as bugz sent mail to the netdev mailing
lists instead of to you?
The best power I have to scale is the delete key in my email
reader, when I delete an email it's gone and that's it.
bugme bugs don't have this attribute, they are like emails that
persist forever until someone does something about them, and this is
the big problem I have with it.
From: "Martin J. Bligh" <[email protected]>
Date: Fri, 27 Jun 2003 15:47:22 -0700
--"David S. Miller" <[email protected]> wrote (on Friday, June 27, 2003 14:44:26 -0700):
> People DON'T understand. I _WANT_ them to be able to
> fall through the cracks.
I fail to see your point here. If that's what you want, then just
don't look at the bugme data.
bugme bugs persist, when I delete an email it doesn't get deleted
from the bugme database (at least when I go and view it).
Let me draw a diagram for you, say we have 3 contributors A B and
C. They watch the mailing lists, analyze bugs, and work on new
features. They work on what they want to, by the very nature of
open-source development. When a bug hits a mailing list the
following might happen:
A is overloaded, he deletes the email.
B has a look, realizes he is not competent in this area
and deletes the email.
C analayzes and fixes the bug.
I want A and B to have never again have to deal with this bug
report. There is zero point in having the capability to "delete"
the email if it persists in some database somewhere, it's not
deleted it's still in the backlog.
If nobody need fear their report get deleted by overload on
the developers, nobody need do anything but be lazy. And that
system does not work, the contribution must be mutual for this
system to work.
This means that when developers are overloaded they can delete
your report and you'll resend it later.
I don't understand why people have no problem understanding that
this system works when it is in the context of lossy networking
protocols (IPV4) and the things that sit on top to ensure reliable
data delivery via retransmit (TCP), but when this idea is proposed
for things involving people and software development they fall to
fear and doubt.
On Fri, Jun 27, 2003 at 05:00:22PM -0700, David S. Miller wrote:
> From: Ben Greear <[email protected]>
> Date: Fri, 27 Jun 2003 15:36:30 -0700
>
> So, you'd be happy so long as bugz sent mail to the netdev mailing
> lists instead of to you?
>
> The best power I have to scale is the delete key in my email
> reader, when I delete an email it's gone and that's it.
>
> bugme bugs don't have this attribute, they are like emails that
> persist forever until someone does something about them, and this is
> the big problem I have with it.
I've proposed this before and nobody listened but maybe this time...
I think what you want is a bug database which distinguishes between
filed bugs and reviewed bugs. You want to capture all bug reports,
as Alan says (he's right, there is no question about it, you need to
capture the data). You also want an *automatic* way for bugs to just
rot. Anyone can file a bug but unless someone with expertise in the
area reviews the bug and agrees to do something about it, the bug rots.
It's level 1 (capture) and level 2 (we really need to do something about
this some day). Level 1 will have zillions of duplicates and tons of
other noise. Level 2 should be a small list, no duplicates, carefully
managed.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
From: Alan Cox <[email protected]>
Date: 28 Jun 2003 00:04:30 +0100
it means you can spot patterns, trends
I already spot patterns and trends when people retransmit the
bug/patch/whatever. As do other people.
Frankly, people who aren't willing to maintain their patches
and retransmit them to me, do not matter as far as I am concerned.
If you don't want to put forth the effort, I do not want to interact
with you. I feel the same way about bugs.
Linus has been saying this and doing it for years, and I've had to
learn the hard way that he's absolutely right in this regard. If you
try to track everything, you accomplish nothing. You will, however,
get overloaded and frustrated. To scale one must reserve the right to
hit the delete key and it's _GONE_ not accumulating somewhere else.
We need social engineering. If someone never gets their bug looked at
because they post absolute crap bug reports, that's a feature. If
people spend all this effort making sense of such reports and fix them
_ANYWAYS_ the reporter will never learn to produce high quality bug
reports that are more useful to us. That means the scarcest resource
we have is being used inefficiently.
That same goes for patches, and I've watched over time how this works.
This is another reasone that I hate when people privately email me
stuff, because I _WILL_ delete it and I _WILL_ lose it. If you post
it to the lists, it gets accumulated somewhere but it doesn't clog
my mailbox and it doesn't create a backlog for me. It also means that
if I'm sipping Mai Tai's in Hawaii other people will see and can react
to the report.
From: Alan Cox <[email protected]>
Date: 28 Jun 2003 00:08:56 +0100
Tried doing an SQL query or text analysis for similarities on random
messages lurking in private mailboxes
I respond to private reports with "please send this to the lists,
what if I were on vacation for the next month?" I never actually
process or analyze such reports.
On Fri, Jun 27, 2003 at 06:30:24PM -0400, Ben Collins wrote:
> > - The bugs which are affecting people the most get reported the most.
>
> Not to mention the "breeding" affect. A bug that many people have seen
> only once, but can never pinpoint because they can't reproduce it. One
> of those people reports the problem to the mailing list, and suddenly
> half a dozen respond with "me too, but here's some extra info that I
> saw". You can't get that with a bug database.
I can't believe that I'm dumb enough to ask this given the BK experience.
We've built BugDB technology and we're quite interested in trying to make
a system that works for engineers as well as managers. All that DB crud
is great for managers who want metrics but engineers want an easy way to
deal with the bugs. For example, an email interface. Our bugdb already
has that, the emails include a URL so you can go look at that and do stuff
to it but you can also reply to the email and do everything through the
email interface. An NNTP interface is in the works.
Is there any interest in having us mirror the bugzilla DB and work on
making an interface that works for people with different needs? I had
already assumed that I'd get hissed out of the room if I proposed this
so feel free to say no if that's what you want.
On the other hand, this one is maybe easier to swallow than BK because
the interfaces are standard protocols (SMTP, HTTP, NNTP and maybe IMAP or
POP some day) so you don't have to put your fingers on any evil BitMover
software to get at it.
If you do want us to look at this then I'd suggest that you elect someone
to come up with a proposal that the community finds acceptable, i.e., if
you use it then we have to do some stuff like
- free access for everyone
- data exported in CSV form so other people can get at it
- ???
If you say you want it then we have to figure out some way that
the community is happy up front. I'd suggest that Alan define the
relationship, he has credibility, he doesn't like BK, he's smart enough
to not get talked into something unreasonable, etc.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
--"David S. Miller" <[email protected]> wrote (on Friday, June 27, 2003 17:00:22 -0700):
> From: Ben Greear <[email protected]>
> Date: Fri, 27 Jun 2003 15:36:30 -0700
>
> So, you'd be happy so long as bugz sent mail to the netdev mailing
> lists instead of to you?
>
> The best power I have to scale is the delete key in my email
> reader, when I delete an email it's gone and that's it.
>
> bugme bugs don't have this attribute, they are like emails that
> persist forever until someone does something about them, and this is
> the big problem I have with it.
Right ... but if bugs were sent to netdev or whatever, you'd get
something similar to what you have today, as long as *you* don't
go looking in bugme (which you've made it clear you won't). Other
people seem to find this useful, and they can still go use it if
they like.
So presumably that'd work out OK?
M.
--Larry McVoy <[email protected]> wrote (on Friday, June 27, 2003 17:19:54 -0700):
> On Fri, Jun 27, 2003 at 05:00:22PM -0700, David S. Miller wrote:
>> From: Ben Greear <[email protected]>
>> Date: Fri, 27 Jun 2003 15:36:30 -0700
>>
>> So, you'd be happy so long as bugz sent mail to the netdev mailing
>> lists instead of to you?
>>
>> The best power I have to scale is the delete key in my email
>> reader, when I delete an email it's gone and that's it.
>>
>> bugme bugs don't have this attribute, they are like emails that
>> persist forever until someone does something about them, and this is
>> the big problem I have with it.
>
> I've proposed this before and nobody listened but maybe this time...
>
> I think what you want is a bug database which distinguishes between
> filed bugs and reviewed bugs. You want to capture all bug reports,
> as Alan says (he's right, there is no question about it, you need to
> capture the data). You also want an *automatic* way for bugs to just
> rot. Anyone can file a bug but unless someone with expertise in the
> area reviews the bug and agrees to do something about it, the bug rots.
>
> It's level 1 (capture) and level 2 (we really need to do something about
> this some day). Level 1 will have zillions of duplicates and tons of
> other noise. Level 2 should be a small list, no duplicates, carefully
> managed.
That's a trivial change to make if you want it. we just add a "reviewed"
/ "certified" state between "new" and "assigned". Yes, might be a good
idea. I'm not actually that convinced that "assigned" is overly useful
in the context of open-source, but that's a separate discussion.
I'm hoping to get a discussion going at Kernel Summit / OLS on how
people want this to evolve, I'll add this one to the list ... thanks.
M.
> I also. The bug database tries to convert the traditional many<->many
> debugging process into a one<->one process. This surely results in a
> lower cleanup rate.
I think your suggestion of sending new bugs out to LKML has made a big
dent in the one<->one problem already. Replacing all the default owner
fields with mailing lists (either existing ones or new ones) instead of
individuals would be another step in that direction, though there may
be a few hurdles to deal with on the way to that.
Yes, we probably also need an "email back in" interface as we've
discussed before to take it up to many-many.
> It is nice to have a record. But bugzilla is not a comfortable or
> productive environment within which to drill down into and fix problems.
OK ... But I'd rather try to fix it than to throw the baby out with the
bath water. I don't believe it's "unfixable" - the concept of tracking
bugs / problems and making sure they're closed out still seems sound to me.
As an example, I've seen several examples already where I've pestered
people about bugs that already had patches attatched to them that resulted
in "oh, yeah, I forgot to actually submit that", and it's got fixes back
into mainline. I find it somewhat hard to believe that just about every
other big project (including open source ones) uses some form of bug
tracking system, and yet Linux is somehow magically different ;-)
M.
From: "Martin J. Bligh" <[email protected]>
Date: Fri, 27 Jun 2003 17:15:50 -0700
So presumably that'd work out OK?
Yes, people can go live in their own bugme world if they want to, I
can't force people not to use it.
But a bug database that the actual maintainers refuse to use seems
quite pointless to me.
From: Larry McVoy <[email protected]>
Date: Fri, 27 Jun 2003 15:53:05 -0700
- one key observation: let bugs "expire" much like news expires. If
nobody has been whining enough that it gets into the high signal
bug db then it probably isn't real. We really want a way where no
activity means let it expire.
I want more than time based expiry, I want expiry for me that
is controlled by me. When I delete the notification email in
my mailbox, I never want to see that bug again unless I want to.
This effectively degrades into list posting based bug reports and my
current email inbox, which is what I'm advocating to use :-)
When I see the "me too, heres some more info" response to the list
posting, then I'm interested and I'll reread the list thread to
digest all the information to see what I can make of it. When this
happens bugs basically fix themselves, and this occurs only because
of the acts taken on by the reporters of the bug not me.
"Martin J. Bligh" <[email protected]> wrote:
>
> I think your suggestion of sending new bugs out to LKML has made a big
> dent in the one<->one problem already. Replacing all the default owner
> fields with mailing lists (either existing ones or new ones) instead of
> individuals would be another step in that direction, though there may
> be a few hurdles to deal with on the way to that.
>
> Yes, we probably also need an "email back in" interface as we've
> discussed before to take it up to many-many.
Both these things would help heaps - the tracking system then
becomes invisible, basically. The best of both. Can we make it so?
--Andrew Morton <[email protected]> wrote (on Friday, June 27, 2003 18:14:32 -0700):
> "Martin J. Bligh" <[email protected]> wrote:
>>
>> I think your suggestion of sending new bugs out to LKML has made a big
>> dent in the one<->one problem already. Replacing all the default owner
>> fields with mailing lists (either existing ones or new ones) instead of
>> individuals would be another step in that direction, though there may
>> be a few hurdles to deal with on the way to that.
>>
>> Yes, we probably also need an "email back in" interface as we've
>> discussed before to take it up to many-many.
>
> Both these things would help heaps - the tracking system then
> becomes invisible, basically. The best of both. Can we make it so?
The answer to both is yes, but one's harder than the other ;-)
1. default owners -> lists:
Setting default owners to existing lists is somewhat invasive, and
might provoke riots ;-) Not only do you get the new bug notification,
but also any updates, which may become irritating. There's probably
some vaguely happy medium to be found between:
a) sending newly logged bugs to existing lists,
b) sending updates to some new list.
Maybe if we just create a new list for each category, and let
people subscribe at will to those ... and I keep sending newly logged
bugs to linux-kernel? I can cc netdev / linux-scsi / whatever on those
new ones if that helps?
That seems reasonably helpful and non-invasive to people who don't
want to see it to me. People who like the mailing lists will see the
new bug reports, and can just delete and forget them (as now). I'll
go with the consensus of opinion (ha!) on this ... I'd like to make
it useful without getting lynched ;-) Using new lists makes it less
intrusive. Any way we go here is fairly easy to set up.
2. email back in.
Email back in is harder, and needs more thought as to how to make it
easy to use, whilst avoiding logging crap (eg. ensuing flamewars that
derive from the bug reports, etc). My intuition is to log replies by
default, and hack off certain threads by hand by keeping track of
replies-to headers or something. Not desperately enamoured with that,
but it's the best I can think of, off the top of my head. Open to
other ideas ...
Anyway, that bit is definitely a longer term project (ie not going to
happen next week, but maybe in a few weeks).
M.
"Martin J. Bligh" <[email protected]> wrote:
>
> 1. default owners -> lists:
>
> Setting default owners to existing lists is somewhat invasive, and
> might provoke riots ;-) Not only do you get the new bug notification,
> but also any updates, which may become irritating.
That's OK. It is a matter of people being aware that the updates will be
echoed to a mailing list and acting appropriately.
If some low-value stuff leaks through then ho-hum, at least it was
on-topic. It is not as if we are unused to low-value content...
It would be good if pure administrata such as changing the status were
filtered.
In fact, there is probably no point in sending anything bugzilla->list apart
from the initial report. If the bug is then pursued via bugzilla then OK.
If is is pursued via email then bugzilla just captures the discussion.
> There's probably
> some vaguely happy medium to be found between:
> a) sending newly logged bugs to existing lists,
> b) sending updates to some new list.
> Maybe if we just create a new list for each category, and let
> people subscribe at will to those ... and I keep sending newly logged
> bugs to linux-kernel? I can cc netdev / linux-scsi / whatever on those
> new ones if that helps?
I think sending the initial report to the relevant lists and then capturing
incoming email would suffice.
> 2. email back in.
>
> Email back in is harder, and needs more thought as to how to make it
> easy to use, whilst avoiding logging crap (eg. ensuing flamewars that
> derive from the bug reports, etc).
Well hopefully people will have the sense to cut the bugzilla address off
the Cc line if it drifts off-topic.
> My intuition is to log replies by
> default, and hack off certain threads by hand
Nah. Just log everything and hack off the crap by larting people.
I think what you need to ensure is a "push" operation with retransmits.
Obvioulsy the "pull"ing of Dave to bugzilla hasnt worked
(otherwise this discussion wouldnt be happening).
Bug trackers have never worked for me either - in my current day
job i am now passed notifications of every bugzuilla opened. I
actually asked for this because i hate checking bugzilla.
Over time heres what happened:
month 0-3: Read the whole thing and called the owner.
month 4-5: Spent about a 30 second glance and may email somebody
month 6-9: Spend about 30 secs and archive them in a separate maibox
month 9-12: fuck this shit. procmail the whole thing. That what procmail
is for! Maybe someday over a fine cup of Tim Hortons French Vanilla
cappucino and donut i'll go over that list and read them all- if only we
had krispy creme donuts to go with Tim hortons coffee then i am sure i
will read them ;-> The truth is i drink Tim Hortons capucino but still
dont read the damn bugzilla mailbox. But i have it just in case i need
it ...
I can almost swear this is what will happen when you start ccing Dave
on bugzillas.
If you think of Dave as a server then the most reliable protocol
is to retransmit. Under resource constraint he dumps packets
(that del key). Add another server - Alexey - and broadcast to both
via netdev and you start to scale.
I dont think retransmission by a robot would work well either since
it misses that human touch. So you have a challenging task.
cheers,
jamal
> If some low-value stuff leaks through then ho-hum, at least it was
> on-topic. It is not as if we are unused to low-value content...
;-)
> It would be good if pure administrata such as changing the status were
> filtered.
That should be easy enough.
> In fact, there is probably no point in sending anything bugzilla->list apart
> from the initial report. If the bug is then pursued via bugzilla then OK.
> If is is pursued via email then bugzilla just captures the discussion.
OK, but I'm pretty much doing that already. I try to filter out some of
the "bugs with no content". So it sounds like the issue is more the
loop from email back in. Will see what I can get done - have to schedule
some time from the admins.
>> 2. email back in.
>>
>> Email back in is harder, and needs more thought as to how to make it
>> easy to use, whilst avoiding logging crap (eg. ensuing flamewars that
>> derive from the bug reports, etc).
>
> Well hopefully people will have the sense to cut the bugzilla address off
> the Cc line if it drifts off-topic.
Fairy nuff.
>> My intuition is to log replies by
>> default, and hack off certain threads by hand
>
> Nah. Just log everything and hack off the crap by larting people.
Heh. need to get a good "remote slap protocol" implemented. Perhaps
the net guys can write us an RFC for it ;-)
M.
> > > It would also keep bugs from falling through the cracks:
> > >
> > > People DON'T understand. I _WANT_ them to be able to
> > > fall through the cracks.
> >
> > I fail to see your point here.
>
> This might help. Or not.
>
> Brain dump on the bug tracking problem from the Kernel Summit discussions
I implemented the vast majority of this months ago, in my bug database:
http://www.grabjohn.com/kernelbugdatabase/
> [SCCS/s.BUGS vers 1.3 2001/04/05 13:10:10]
>
> Outline
> Problems
> Problem details
> Past experiences
> Requirements
>
> Problems
> - getting quality bug reports
> - not losing any bugs
> - sorting low signal vs high signal into a smaller high signal pile
> - simplified, preferably NNTP, access to the bug database (Linus
> would use this; he's unlikely to use anything else)
>
> Problem details
> Bug report quality
> There was lots of discussion on this. The main agreement was that we
> wanted the bug reporting system to dig out as much info as possible
> and prefill that. There was a lot of discussion about possible tools
> that would dig out the /proc/pci info; there was discussion about
> Andre's tools which can tell you if you can write your disk; someone
> else had something similar.
This is controversial, due to the potential for unwanted information
disclosure. I purposely didn't implement it. If a large proportion
of users want it implemented, just let me know.
> But the main thing was to extract all the info we could
> automatically. One thing was the machine config (hardware and
> at least kernel version). The other thing was extract any oops
> messages and get a stack traceback.
The (fairly complex) way kernel tree version numbers are implemented
is very well handled. Different trees can be added to the database,
using an admin utility, (which is not currently publically
accessible), and they are categorised. Currently we have 2.4 and 2.5
mainline, 2.4 and 2.5 -ac, and 2.5 -dj trees in the database. All
version numbers are sorted properly with -pre and -rc coming before
the release.
> The other main thing was to define some sort of structure to the
> bug report and try and get the use to categorize if they could.
> In an ideal world, we would use the maintainers file
Did that since version 1.0.
> and the
> stack traceback to cc the bug to the maintainer. I think we want
> to explore this a bit. I'm not sure that the maintainer file is
> the way to go, what if we divided it up into much broader chunks
> like "fs", "vm", "network drivers", and had a mail forwarder
> for each area. That could fan out to the maintainers.
No problem. The admin utility can scan any file which is in the same
format as the current maintainers file. Just prepare and upload one.
> Not losing bugs
> While there was much discussion about how to get rid of bad,
> incorrect, and/or duplicate bug reports, several people - Alan
> in particular - made the point that having a complete collection
> of all bug reports was important. You can do data mining across
> all/part of them and look for patterns. The point was that there
> is some useful signal amongst all the noise so we do not want to
> lose that signal.
Done since version 2.0. We have bug reports, and confirmed bugs. Bug
reports are archived after 2 weeks of inactivity, (or should be, I
introduced a bug recently which stopped that working, but I'll fix
that at the earliest opportunity). Anybody can add a bug report, and
they are all archived. Confirmed bugs can only be added by admins,
and collect together bug reports.
> Signal/noise
> We had a lot of discussion about how to deal with signal/noise.
> The bugzilla proponents thought we could do this with some additional
> hacking to bugzilla. I, given the BitKeeper background, thought
> that we could do this by having two databases, one with all the
> crud in it and another with just the screened bugs in it.
See above - done since version 2.0.
> No matter
> how it is done, there needs to be some way to both keep a full list,
> which will likely be used only for data mining, and another, much
> smaller list of screened bugs.
Confirmed bugs VS bug reports.
> Jens wants there to be a queue of
> new bugs and a mechanism where people can come in the morning, pull
> a pile of bugs off of the queue, sort them, sending some to the real
> database.
No problem - just deselect 'include bug reports', and 'include
archived entries', and click 'All entries'. Then, (you need to have
an admin account for this), select 'open a new confirmed bug'. Add
the bug reports to this confirmed bug.
> This idea has a lot of merit, it needs some pondering as
> DaveM would say, to get to the point that we have a workable mechanism
> which works in a distributed fashion.
>
> The other key point seemed to be that if nobody picked up a bug and
> nobody said that this bug should be picked up, then the bug expires
> out of the pending queue. It gets stashed in the bug archive for
> mining purposes and it can be resurrected if it later becomes a real
> bug, but the key point seems to be that it _automatically_ disappears
> out of the pending queue. I personally am very supportive of this
> model. We need some way to just let junk stay junk. If junk has to
> be pruned out of the system by humans, the system sucks. The system,
> not humans, needs to autoprune.
It does autoprune. (OK, there is currently a bug which is preventing
it from working, but as I said above, I'll fix that as soon as I get
chance to work on it). Bug reports over two weeks old become archived.
> Simplified access: browsing and updating
> Linus made the point that mailing lists suck. He isn't on any and
> refuses to join any. He reads lists with a news reader. I think
> people should sit up and listen to that - it's a key point. If your
> mailing list isn't gatewayed to a newsgroup, he isn't reading it and
> a lot of other people aren't either.
>
> There was a fair bit of discussion about how to get the bug database
> connected to news. There doesn't seem to be any reason that the
> bug system couldn't be a news server/gateway. You should be able to
> browse
> bitbucket.kernel.bugs - all the unscreened crud
> screened.kernel.bugs - all bugs which have been screened
> fs.kernel.bugs - screened bugs in the "fs" category
> ext2.kernel.bugs - screened bugs in the "ext2" category
> eepro.kernel.bugs - screened bugs in the "eepro" category
> etc.
Not yet implemented. Let me know more specifically what you want, and
I'll implement it.
Note - there _was_ a prefectly good command line/E-Mail interface, but
hardly anybody used it, so I removed it.
> Furthermore, the bugs should be structured once they are screened,
> i.e., they have a set of fields like (this is a strawman):
>
> Synopsis - one line man-page like summary of the bug
Implemented.
> Severity - how critical is this bug?
> Priority - how soon does it need to be fixed?
Not implemented, but trivial to implement if people care.
> Category - subsystem in which the bug occurs
Implemented via Maintainers file.
> Description - details on the bug, oops, stack trace, etc.
Implemented.
> Hardware - hardware info
> Software - kernel version, glibc version, etc.
> Suggested fix - any suggestion on how to fix it
> Interest list - set of email addresses and/or newsgroups for updates
Not implemented, but trivial to implement if people care.
> It ought to work that if someone posts a followup to the bug then if
> the followup changes any of the fields that gets propagated to the
> underlying bug database. If this is done properly the news reader will
> be the only interface that most people use.
OK, my idea is a bit different - each possibly widely differing bug
report is a completely separate entity. You can only add to a bug
report, unless you are the submitter, or an admin. Anybody else
should add a separate bug report, and have an admin find and connect
it to the existing confirmed bug.
> Past experiences
> This is a catch all for sound bytes that we don't want to forget...
>
> - Sorting bugs by hand is a pain in the ass (Ted burned out on it and
> Alan refuses to say that it is the joy of his life to do it)
Bug reports are sorted via the categories in the maintainers file.
Anybody can 'watch' any particular subsystem and get notified of all
the bug reports that are submitted as included in that subsystem. A
bug report can go in to more than one subsystem or none at all.
> - bug systems tend to "get in the way". Unless they are really trivial
> to submit, search, update then people get tired of using them and go
> back to the old way
Isn't this exactly what we're seeing with a lot of bugs in the kernel
Bugzilla being forwarded to LKML? We shouldn't need that if the bug
database is operating satisfactorily.
> - one key observation: let bugs "expire" much like news expires. If
> nobody has been whining enough that it gets into the high signal
> bug db then it probably isn't real. We really want a way where no
> activity means let it expire.
Done.
> - Alan pointed out that having all of the bugs someplace is useful,
> you can search through the 200 similar bugs and notice that SMP
> is the common feature.
Done - just make sure 'include archived entries' is selected.
> Requirements
> This section is mostly empty, it's here as a catch all for people's
> bullet items.
>
> - it would be very nice to be able to cross reference bugs to bug fixes
> in the source management system, as well as the other way around.
Larry, if you can provide pointers as to the best way to link to stuff
in BK, I'm happy to put that in.
> - mail based interface
Removed, because nobody used it. You can still see screenshots of it
at:
http://www.grabjohn.com/kernelbugdatabase/screenshots/
You can find the Kernel Bug Database at:
http://www.grabjohn.com/kernelbugdatabase/
or alternatively, the database and documentation are linked to from:
http://www.grabjohn.com/
If there are problems with it, or reasons why people hate it, please
_let me know_.
John.
> > This might help. Or not.
> >
> > Brain dump on the bug tracking problem from the Kernel Summit discussions
>
> I implemented the vast majority of this months ago, in my bug database:
>
> http://www.grabjohn.com/kernelbugdatabase/
>
[snip]
> > Problem details
> > Bug report quality
> > There was lots of discussion on this. The main agreement was that we
> > wanted the bug reporting system to dig out as much info as possible
> > and prefill that. There was a lot of discussion about possible tools
> > that would dig out the /proc/pci info; there was discussion about
> > Andre's tools which can tell you if you can write your disk; someone
> > else had something similar.
>
> This is controversial, due to the potential for unwanted information
> disclosure. I purposely didn't implement it. If a large proportion
> of users want it implemented, just let me know.
Having said that, I've had a .config uploading and analysing facility
since version 1.0. Infact, the reason I forgot to mention it in my
first E-Mail, is that it is the core around which the whole Kernel Bug
Database operates. The user uploads their .config, and the database
finds bugs that might be the one you're experiencing. If so, you add
a separate bug report, an admin collects both bug reports in to one
confirmed bug, and picks out which config options he wants to flag as
causing the confirmed bug.
John.
On Sad, 2003-06-28 at 01:21, David S. Miller wrote:
> From: Alan Cox <[email protected]>
> Date: 28 Jun 2003 00:08:56 +0100
>
> Tried doing an SQL query or text analysis for similarities on random
> messages lurking in private mailboxes
>
> I respond to private reports with "please send this to the lists,
> what if I were on vacation for the next month?" I never actually
> process or analyze such reports.
Which means you miss stuff. Here is an example my tools found yesterday
18 months ago someone with a specific printer reported doing network printing
to it crashed the kernel. Lost in the noise, filed in bugzilla, categorised
mentally at the time as "weird".
Not long ago a second identical report popped up. Different setup, same
network printing, similar "it reboots" report.
So now I've gone chasing tcpdumps from these.
Its a *different* thing to the kind of patch management you are doing, but its
only possible because of tools like bugzilla
On Sad, 2003-06-28 at 01:27, Martin J. Bligh wrote:
> That's a trivial change to make if you want it. we just add a "reviewed"
> / "certified" state between "new" and "assigned". Yes, might be a good
> idea. I'm not actually that convinced that "assigned" is overly useful
> in the context of open-source, but that's a separate discussion.
Most bugzilla's seem to use VERIFIED for this, and it means people who
have better things to do can just pull bugs that are verified and/or
tagged with "patch" in the attachments
On Sad, 2003-06-28 at 01:32, Larry McVoy wrote:
> Is there any interest in having us mirror the bugzilla DB and work on
> making an interface that works for people with different needs? I had
> already assumed that I'd get hissed out of the room if I proposed this
> so feel free to say no if that's what you want.
I already pull chunks of bugzilla data into plain text for processing,
the more formats and tools the better. You can do a lot of great things
with large sets of bugzilla data when you throw it at a text indexing
engine for example.
One of my todo list items is to learn enough emacs to play with feeding
bugzilla data into the remembrance agent and seeing what happens
From: Alan Cox <[email protected]>
Date: 28 Jun 2003 20:19:32 +0100
On Sad, 2003-06-28 at 01:21, David S. Miller wrote:
> I respond to private reports with "please send this to the lists,
> what if I were on vacation for the next month?" I never actually
> process or analyze such reports.
Which means you miss stuff.
Not my problem Alan. If the user gives a crap about their report
mattering, they'll do what I ask them to do. If users send their
report to the wrong place, it will get lost, just like if their
cat their report into /dev/null. I have no reason to feel bad about
the information getting lost.
If it's too much for them to do as I ask, it's too much for
me to consider their report.
Bug reporting, just like patch submission, is a 2 way street.
> If users send their report to the wrong place, it will get lost,
> just like if their cat their report into /dev/null. I have no reason
> to feel bad about the information getting lost.
Also, remember that we sometimes get no response when something is
fixed, which is especially true when the fix happens by itself.
E.G.
2.5.foo released
Bug reported to LKML, and nobody responds.
2.5.bar released
Bug re-reported to LKML, still nobody answers, maybe it's not a very
detailed bug report, or everybody is too busy.
2.5.baz released
No bug report.
We have so far been assuming in this discussion that 2.5.baz won't
have fixed the bug. It's not entirely impossible that 2.5.baz _will_
have fixed the bug - maybe a subsystem was being overhauled anyway,
and it was generally known on the list that the bug existed.
By not letting bug reports expire, we'd have a lot of unclosed bugs
that were really fixed.
There is an analogy with TCP:
Compare:
SYN -->
<-- ACK
DATA -->
FIN -->
and
SYN -->
<-- ACK
DATA -->
with:
Bug report -->
Bug report -->
<-- Please test this patch
Follow up bug report -->
<-- Please test this patch
Follow up bug report -->
<-- Please test this patch
OK, thanks, it works -->
<-- Glad it worked
and
Bug report -->
Bug report -->
<-- Please test this patch
Follow up bug report -->
<-- Please test this patch
<-- Please test this patch
<-- Please test this patch
> If it's too much for them to do as I ask, it's too much for
> me to consider their report.
>
> Bug reporting, just like patch submission, is a 2 way street.
It's not even a case of effort, more that you need 2 way communication
to successfully fix a bug. You need to know that the fix worked
initially, continues to work, and that it doesn't break anything else,
otherwise you might be adding more bugs.
John.
On Sad, 2003-06-28 at 23:03, David S. Miller wrote:
> Not my problem Alan. If the user gives a crap about their report
> mattering, they'll do what I ask them to do. If users send their
> report to the wrong place, it will get lost, just like if their
> cat their report into /dev/null. I have no reason to feel bad about
> the information getting lost.
You might not care but some of us do. Capturing the data matters for
lots of things. That you don't have the time to be the filter for that
info for networking is also fine.
From: Alan Cox <[email protected]>
Date: 29 Jun 2003 00:15:38 +0100
You might not care but some of us do. Capturing the data matters for
lots of things. That you don't have the time to be the filter for that
info for networking is also fine.
Alan, you really stretch yourself thin doing this stuff
all the time.
Now imagine if you invested this effort in educating people
and getting them to be better bug reporters, sending the
right info to the right place?
I think that, along with some actual development I actually miss
seeing you be able to do that, is a much better allocation of your
time and talents.
You're grovelling at the bottom of the barrel, it's time to start
skimming from the top instead. Things that matters will come back, it
doesn't disappear.
On Sul, 2003-06-29 at 00:20, David S. Miller wrote:
> Now imagine if you invested this effort in educating people
> and getting them to be better bug reporters, sending the
> right info to the right place?
For IDE the statistical value of being able to go digging through old
data has been more than worth the effort. Similarly writing tools to do
the grovelling has a clear value.
> You're grovelling at the bottom of the barrel, it's time to start
> skimming from the top instead. Things that matters will come back, it
> doesn't disappear.
I'm trying to turn grovelling into barrels into an automated process.
Thats much more useful and also entertaining (things like oops matching
and gdb trace matching turn out to be interesting little problems of
their own)
Alan
On Sat, Jun 28, 2003 at 08:20:53PM +0100, Alan Cox wrote:
> On Sad, 2003-06-28 at 01:27, Martin J. Bligh wrote:
> > That's a trivial change to make if you want it. we just add a "reviewed"
> > / "certified" state between "new" and "assigned". Yes, might be a good
> > idea. I'm not actually that convinced that "assigned" is overly useful
> > in the context of open-source, but that's a separate discussion.
>
> Most bugzilla's seem to use VERIFIED for this, and it means people who
> have better things to do can just pull bugs that are verified and/or
> tagged with "patch" in the attachments
GCC just calls this "UNCONFIRMED" vs. "NEW", which seems to work well.
A lot of the maintainers don't look at Bugzilla at all, and a lot of
the rest filter out UNCONFIRMED. A couple of interested (and
dumbfoundingly dedicated) people review and confirm bugs; that's less
possible with the Linux kernel, since bugs often require hardware to
reproduce, but the principle is still sound.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
--Alan Cox <[email protected]> wrote (on Saturday, June 28, 2003 20:20:53 +0100):
> On Sad, 2003-06-28 at 01:27, Martin J. Bligh wrote:
>> That's a trivial change to make if you want it. we just add a "reviewed"
>> / "certified" state between "new" and "assigned". Yes, might be a good
>> idea. I'm not actually that convinced that "assigned" is overly useful
>> in the context of open-source, but that's a separate discussion.
>
> Most bugzilla's seem to use VERIFIED for this, and it means people who
> have better things to do can just pull bugs that are verified and/or
> tagged with "patch" in the attachments
Hmmm. we have VERIFIED set up to mean that the proposed fix has been
verified to work. Could reshuffle it, or we could find a different
word I guess - reusing the same one might cause confusion (on the
other hand ...using the same word for different things in different
bugzillas is confusing too ...)
M.
From: Alan Cox <[email protected]>
Date: 28 Jun 2003 00:04:30 +0100
You are assuming there is a relationship in bug severity/commonness
and number of *developers* who hit it.
Not true, the assumption I make is that a bug report that
a bug reporter cares about, and a patch that a patch submitter
cares about, will all get resent if they get dropped.
If the reporter/submitter doesn't care, neither do I.
You keep saying that lost information is bad and serves no
positive purpose, and I totally disagree. Drops are litmus tests
for the patch/report, they also serve to educate the submitters.
And to repeat, this process is a two way street Alan. If you try to
make it anything else, you will wear yourself thin.
Once you enforce the work to be distributed to the people who report
to you as much as to the people taking the reports, thing will go much
more smoothly. :-)
On Sun, Jun 29, 2003 at 02:15:28PM -0700, David S. Miller wrote:
> From: Alan Cox <[email protected]>
> Date: 28 Jun 2003 00:04:30 +0100
>
> You are assuming there is a relationship in bug severity/commonness
> and number of *developers* who hit it.
>
> Not true, the assumption I make is that a bug report that
> a bug reporter cares about, and a patch that a patch submitter
> cares about, will all get resent if they get dropped.
>
> If the reporter/submitter doesn't care, neither do I.
You are right, but only in the part where you say that this
is the best, indeed the only, way you can work.
Alan is right, information is important, and a lot of it is
submitted only once. (And a lot of it is submitted three times
and ignored three times.)
Suppose you find a gcc bug, construct a small example that
is mistranslated and send it off to the gcc list. Maybe even
include a fix. Will you babysit them, check whether later snapshots
correct this flaw, resubmit your report every month if not?
Maybe you will. I certainly don't - send the report and that's it.
Andries
From: Andries Brouwer <[email protected]>
Date: Sun, 29 Jun 2003 23:45:58 +0200
Will you babysit them, check whether later snapshots correct this
flaw, resubmit your report every month if not? Maybe you will. I
certainly don't - send the report and that's it.
And like evolution and many other processes in life, the things
that put forth the effort will tend to get further and accomplish
more.
As a result, your bug reports will tend to not be tended to,
whilst those of the persistent people will. People who care
about their bug reports learn the become persistent or accept
that their bugs tend to not get looked at.
People who expect that, for free, one bug submission will get
their bug fixed and this is somehow ensured are truly living
in a dream world.
Let's see, what makes more sense from my perspective. Should I reward
and put forth effort for the people who fart a bug report onto the
lists and expect everyone to stop what they're doing and fix the bug,
or should I reward and put forth effort for the guy who spent the time
to put together a stellar bug report and also doesn't mind
retransmitting it from time to time whilst everyone is busy?
On Sul, 2003-06-29 at 22:15, David S. Miller wrote:
> You keep saying that lost information is bad and serves no
> positive purpose, and I totally disagree. Drops are litmus tests
> for the patch/report, they also serve to educate the submitters.
What you don't get is that like you I'm distributing work. I'm getting
end users to spot bug correlations - and thats why I want better tools
Report bug should get
Your bug looks like #1131 #4151 or #11719 (Resolved), please check
From: Alan Cox <[email protected]>
Date: 29 Jun 2003 23:07:07 +0100
What you don't get is that like you I'm distributing work. I'm
getting end users to spot bug correlations - and thats why I want
better tools
I understand this part, it's great sounding in theory.
But all the examples I've seen are you sifting through bugzilla making
these correlations. I've seen no evidence of community participation
in this activity.
The greatest tools in the world aren't useful if people don't want
to use them.
Nobody wants to use tools unless it melds easily into their existing
daily routine. This means it must be email based and it must somehow
work via the existing mailing lists. It sounds a lot like what I'm
advocating except that there's some robot monitoring the list
postings.
But then who monitors and maintains the entries? That's the big
problem and I haven't heard a good solution yet. Going to a web site
and clicking buttons is not a solution. That's a waste of time.
> Report bug should get
> Your bug looks like #1131 #4151 or #11719 (Resolved), please check
Note that my bug database actually does that, and has done for months,
when somebody uploads their .config.
John.
On Sun, Jun 29, 2003 at 02:51:14PM -0700, David S. Miller wrote:
> From: Andries Brouwer <[email protected]>
> Date: Sun, 29 Jun 2003 23:45:58 +0200
>
> Will you babysit them, check whether later snapshots correct this
> flaw, resubmit your report every month if not? Maybe you will. I
> certainly don't - send the report and that's it.
>
> As a result, your bug reports will tend to not be tended to,
Maybe that is the wrong answer. It seems they have a bug tracking system.
> People who expect that, for free, one bug submission will get
> their bug fixed
See, you think you are doing the submitter a favour.
I prefer the point of view that the submitter does us a favour.
Something is wrong, and people work around it.
But they tell us about it. If we want we can try to fix.
Or we can store the information for later examination.
Very often it is needed later - fortunately Google helps.
A more focused data base might help even better.
On Mon, 30 Jun 2003, Andries Brouwer wrote:
> See, you think you are doing the submitter a favour.
> I prefer the point of view that the submitter does us a favour.
You the winner !
You answered correctly to my previous question ;)
- Davide
--"David S. Miller" <[email protected]> wrote (on Sunday, June 29, 2003 15:13:02 -0700):
> From: Alan Cox <[email protected]>
> Date: 29 Jun 2003 23:07:07 +0100
>
> What you don't get is that like you I'm distributing work. I'm
> getting end users to spot bug correlations - and thats why I want
> better tools
>
> DaveM:
> I understand this part, it's great sounding in theory.
>
> But all the examples I've seen are you sifting through bugzilla making
> these correlations. I've seen no evidence of community participation
> in this activity.
People have been. Maybe not with the networking bugs, but I've seen
people sift through other stuff, and mark off duplicates, and point
out similarities. People go chase attatched patches back into the tree,
and people test fixes they didn't submit the bug for, and report status.
I'd like more of that, but it happens already.
> The greatest tools in the world aren't useful if people don't want
> to use them.
>
> Nobody wants to use tools unless it melds easily into their existing
> daily routine. This means it must be email based and it must somehow
> work via the existing mailing lists. It sounds a lot like what I'm
> advocating except that there's some robot monitoring the list
> postings.
Agreed, the interface could be better - we're working on it. It won't
be totally change free, but it could be better integrated. Feedback is
very useful, though it helps a lot of you can pinpoint what's the
underlying issue rather than "this is crap". Better email integration
is top of the list, starting with sending stuff out to multiple people
when filed, not a single bottleneck point.
> But then who monitors and maintains the entries? That's the big
> problem and I haven't heard a good solution yet. Going to a web site
> and clicking buttons is not a solution. That's a waste of time.
There is an army of elves out there, quite capable and willing.
Like most change, it takes a little time, but it's started already.
> AEB:
>
> See, you think you are doing the submitter a favour.
> I prefer the point of view that the submitter does us a favour.
Absolutely. Personally, I think testing & communication with users is
more what we're lacking as a community than coding power. In Dave's
case, it sounds like he's so swamped, it's not an issue for him.
However, finding and fixing stuff earlier on will actually reduce
the workload, IMHO. It's a damned sight easier to find a bug you wrote
yesterday than one you wrote last year. I *love* things like nightly
regression testing that reaches out and larts me with a bug report
in < 24 hrs of me screwing things up.
Lastly, I'd rather ditch bug reports based on crap content, or overall
impact, than whether I happened to be busy at the moment they came in.
M.
On Sat, Jul 12, 2003 at 10:07:42AM -0700, Jan Rychter wrote:
> It hasn't. The result is a system that works for you (and other active
> developers), but not for everyone. As an example -- try running Linux on
> a modern laptop, connecting some USB devices, using ACPI, or
> bluetooth. Observe the resulting problems and crashes. You'll hit loads
> of obscure bugs that have been reported, but never got looked at in
> detail. I certainly have hit them and reported most, and most got
> dropped in various places.
What USB bugs have you reported that have gotten dropped?
Note, a _lot_ of USB bluetooth devices are real flaky, not much the
kernel can do about them :(
greg k-h
On Sat, 12 Jul 2003 10:07:42 -0700
Jan Rychter <[email protected]> wrote:
> Interesting you should think you're 'rewarding' people. I thought your
> goal was to have fun working on cool software and making it
> better. I also thought I had the same goal as a bug-reporter.
>
> When I write software, I care about every bug report and consider people
> doing the reporting a very valuable resource.
The whole game changes when you are stretched as thinly
as I am. Scaling becomes everything, and nitpicking through
vague and poorly composed bug reports is an absolute waste of
my time as networking subsystem maintainer.
If other people want to improve bug reports, put them into
a cute usable database, and munge them along, that's fine with
me.
But _I_ only want to work with things that make the best use
of my limited time.
To be frank and honest, I do things that interest _ME_. And waddling
through poorly made bug reports is anything but interesting, in fact
it's frustrating work. I'd rather implement a software 802.11 stack
or TCP Vegas implementation, THAT is what is a good use of my time
because of my knowledge of how all these kinds of things work in the
Linux networking. I can do things overnight that would take others
weeks.
Having me pillage through a bug database is a poor use of my time and
capabilities. And all of my time is spent reviewing patches and
dealing with the properly composed bug reports anyways, so even if I
enjoyed pillaging through badly made bug reports I couldn't.
People are assuming that just because _I_ don't want to work on the
bad bug reports that I think nobody should. It's the exact opposite.
I can't force other people to do or not do things anyways, just like
everyone trying to somehow make it my "duty" to look at every single
bug report cannot force me to do that.
Dear diary, on Mon, Jun 30, 2003 at 04:35:44AM CEST, I got a letter,
where "Martin J. Bligh" <[email protected]> told me, that...
> --"David S. Miller" <[email protected]> wrote (on Sunday, June 29, 2003 15:13:02 -0700):
..snip..
> > The greatest tools in the world aren't useful if people don't want
> > to use them.
> >
> > Nobody wants to use tools unless it melds easily into their existing
> > daily routine. This means it must be email based and it must somehow
> > work via the existing mailing lists. It sounds a lot like what I'm
> > advocating except that there's some robot monitoring the list
> > postings.
>
> Agreed, the interface could be better - we're working on it. It won't
> be totally change free, but it could be better integrated. Feedback is
> very useful, though it helps a lot of you can pinpoint what's the
> underlying issue rather than "this is crap". Better email integration
> is top of the list, starting with sending stuff out to multiple people
> when filed, not a single bottleneck point.
Actually, it's not difficult to make Bugzilla to do things like sending out ALL
bugs updates emails to certain email adress(es), on a global basis or
per-module. Also, it is relatively easy to make Bugzilla _accept_ bugs updates
through email, from additional comments (+ attachments) to
status/priority/target/... changes.
It works quite nicely for us (ELinks) and it took just few hours to set up
properly (we had to touch the BZ sources, but just a little, the rest are
external support scripts). What is missing is some email interface for querying
the database (shouldn't be difficult to do, though), but if you just want to
file/update bugs, all you need is to:
* have the new bugs posted on the mailing list
* keep bugzilla in the cc list through the whole thread, as long as it's
relevant at least ;-)
* don't remove [Bug 12345] from the subject
If Martin would like some know-how about how to set things up, I could share
what we've done with him.
Kind regards,
--
Petr "Pasky" Baudis
.
Perfection is reached, not when there is no longer anything to add, but when
there is no longer anything to take away.
-- Antoine de Saint-Exupery
.
Stuff: http://pasky.ji.cz/