linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* networking bugs and bugme.osdl.org
@ 2003-06-27  5:30 David S. Miller
  2003-06-27  5:46 ` Martin J. Bligh
  0 siblings, 1 reply; 73+ messages in thread
From: David S. Miller @ 2003-06-27  5:30 UTC (permalink / raw)
  To: linux-kernel; +Cc: linux-net, netdev


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.

^ permalink raw reply	[flat|nested] 73+ messages in thread
* Re: networking bugs and bugme.osdl.org
@ 2003-06-27 15:25 John Bradford
  0 siblings, 0 replies; 73+ messages in thread
From: John Bradford @ 2003-06-27 15:25 UTC (permalink / raw)
  To: davem, matti.aarnio, mbligh; +Cc: linux-kernel, linux-net, netdev

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

^ permalink raw reply	[flat|nested] 73+ messages in thread
* Re: networking bugs and bugme.osdl.org
@ 2003-06-27 16:18 Nicolas Mailhot
  0 siblings, 0 replies; 73+ messages in thread
From: Nicolas Mailhot @ 2003-06-27 16:18 UTC (permalink / raw)
  To: linux-kernel

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

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

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread
* Re: networking bugs and bugme.osdl.org
@ 2003-06-28  8:00 John Bradford
  0 siblings, 0 replies; 73+ messages in thread
From: John Bradford @ 2003-06-28  8:00 UTC (permalink / raw)
  To: lm, mbligh; +Cc: davem, greearb, linux-kernel, linux-net, netdev

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

^ permalink raw reply	[flat|nested] 73+ messages in thread
* Re: networking bugs and bugme.osdl.org
@ 2003-06-28  8:10 John Bradford
  0 siblings, 0 replies; 73+ messages in thread
From: John Bradford @ 2003-06-28  8:10 UTC (permalink / raw)
  To: john, lm, mbligh; +Cc: davem, greearb, linux-kernel, linux-net, netdev

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

^ permalink raw reply	[flat|nested] 73+ messages in thread
* Re: networking bugs and bugme.osdl.org
@ 2003-06-28 22:37 John Bradford
  0 siblings, 0 replies; 73+ messages in thread
From: John Bradford @ 2003-06-28 22:37 UTC (permalink / raw)
  To: alan, davem; +Cc: davidel, greearb, linux-kernel, linux-net, mbligh, netdev

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

^ permalink raw reply	[flat|nested] 73+ messages in thread
* Re: networking bugs and bugme.osdl.org
@ 2003-06-29 22:28 John Bradford
  0 siblings, 0 replies; 73+ messages in thread
From: John Bradford @ 2003-06-29 22:28 UTC (permalink / raw)
  To: alan, davem; +Cc: greearb, linux-kernel, linux-net, mbligh, netdev

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

^ permalink raw reply	[flat|nested] 73+ messages in thread

end of thread, other threads:[~2003-07-20 16:31 UTC | newest]

Thread overview: 73+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-27  5:30 networking bugs and bugme.osdl.org David S. Miller
2003-06-27  5:46 ` Martin J. Bligh
2003-06-27  5:47   ` David S. Miller
2003-06-27  7:59     ` Matti Aarnio
2003-06-27  8:00       ` David S. Miller
2003-06-27 15:00       ` Martin J. Bligh
2003-06-27 14:34     ` Martin J. Bligh
2003-06-27 14:56       ` Davide Libenzi
2003-06-27 21:37         ` David S. Miller
2003-06-27 21:54           ` Ben Greear
2003-06-27 21:54             ` David S. Miller
2003-06-27 22:15               ` Ben Greear
2003-06-27 22:19                 ` David S. Miller
2003-06-27 22:36                   ` Ben Greear
2003-06-28  0:00                     ` David S. Miller
2003-06-28  0:15                       ` Martin J. Bligh
2003-06-28  0:32                         ` David S. Miller
2003-06-28  0:19                       ` Larry McVoy
2003-06-28  0:27                         ` Martin J. Bligh
2003-06-28 19:20                           ` Alan Cox
2003-06-29  0:40                             ` Daniel Jacobowitz
2003-06-29  0:44                             ` Martin J. Bligh
2003-06-27 23:08                   ` Alan Cox
2003-06-28  0:21                     ` David S. Miller
2003-06-28 19:19                       ` Alan Cox
2003-06-28 22:03                         ` David S. Miller
2003-06-28 23:15                           ` Alan Cox
2003-06-28 23:20                             ` David S. Miller
2003-06-28 23:46                               ` Alan Cox
2003-07-12 17:07                           ` Jan Rychter
2003-07-13  4:15                             ` Greg KH
2003-07-14 20:25                               ` USB bugs (was: networking bugs and bugme.osdl.org) Jan Rychter
     [not found]                                 ` <20030714230236.GA7195@kroah.com>
2003-07-15 20:24                                   ` Jan Rychter
2003-07-13  5:22                             ` networking bugs and bugme.osdl.org David S. Miller
2003-07-13  5:42                               ` Jan Rychter
2003-06-27 22:02           ` Davide Libenzi
2003-06-27 21:31             ` Ben Collins
2003-06-27 23:25               ` Andrew Morton
2003-06-27 22:30                 ` Ben Collins
2003-06-28  0:32                   ` Larry McVoy
2003-06-28 19:26                     ` Alan Cox
2003-06-28  0:38                 ` Martin J. Bligh
2003-06-28  1:14                   ` Andrew Morton
2003-06-28  2:13                     ` Martin J. Bligh
2003-06-28  2:35                       ` Andrew Morton
2003-06-28  6:08                         ` Martin J. Bligh
2003-06-28  3:27                       ` Jamal Hadi
2003-06-27 22:02             ` David S. Miller
2003-06-27 22:11               ` Davide Libenzi
2003-06-27 22:13                 ` David S. Miller
2003-06-27 18:50     ` Ben Greear
2003-06-27 21:44       ` David S. Miller
2003-06-27 22:47         ` Martin J. Bligh
2003-06-27 22:53           ` Larry McVoy
2003-06-28  0:44             ` David S. Miller
2003-06-28  0:09           ` David S. Miller
2003-06-27 23:04         ` Alan Cox
2003-06-28  0:19           ` David S. Miller
2003-06-29 21:15           ` David S. Miller
2003-06-29 21:45             ` Andries Brouwer
2003-06-29 21:51               ` David S. Miller
2003-06-29 22:49                 ` Andries Brouwer
2003-06-29 23:21                   ` Davide Libenzi
2003-06-29 22:07             ` Alan Cox
2003-06-29 22:13               ` David S. Miller
2003-06-30  2:35                 ` Martin J. Bligh
2003-07-20 16:46                   ` Petr Baudis
2003-06-27 15:25 John Bradford
2003-06-27 16:18 Nicolas Mailhot
2003-06-28  8:00 John Bradford
2003-06-28  8:10 John Bradford
2003-06-28 22:37 John Bradford
2003-06-29 22:28 John Bradford

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).