Re: Linux 2.6.21

[David Lang <david.lang@digitalinsight.com>]

On Sun, 29 Apr 2007, Dave Jones wrote:

> On Sun, Apr 29, 2007 at 02:05:42AM +0200, Adrian Bunk wrote:
> > On Sat, Apr 28, 2007 at 04:40:31PM -0700, Linus Torvalds wrote:
> > >...
> > > What's the difference between bugzilla and lkml.org? Both have search
> > > buttons. Both archive the old stuff. Both can be pointed to.
> >
> > Mailing lists don't track bugs.
>
> There's no reason they can't.  Store them in folders 'fixed' 'pending'
> 'notabug' etc. Move mails between them when states change.
> reply-to them when necessary. Bounce them. Add people to Ccs. etc. etc.

and archive off the old reports into folders as well. While I don't think that 
closeing a report becouse it hasn't seen an update in a week is reasonable, 
closeing a report that hasn't seen an update or retest in a couple 2.6.x 
releases definantly is (this is a 4-6 month period at the rate of change in the 
kernel the odds are pretty good that the code is no longer the same at that 
point)

> The only remaining piece of the puzzle is "how does everyone see the
> states of the various pools", which could be solved in a number of
> ways, daily uploads to a place on kernel org for eg.

if people are interested in doing this it's not a technicly hard problem.

get bugs to a 'bug maintainer' e-mail address. this can either be a copy of the 
full lkml firehose, or volunteers who pull selected messages from the list, with 
a server that discards duplicates it's safe to have multiple people bounce the 
same message to the bug list, if they forward the message (to add a comment on 
who they think may need to work on it) then it will take manual weeding out of 
duplicates

have an IMAP server available for this address. make it read-only to the world 
and read-write to a list of volunteers who will sort the messages.

sort the messages into the different catagories, with a subfolder for each bug 
(note: the structure at this point is arbtrary, the volunteers can further 
orginise the folders)

with a good IMAP server you can add the address of the particular bug folder to 
the cc list if you want (bugs+drivers.ethernet.3com.123@kernel.org for a complex 
example) to have the follow-ups go directly into that folder.

now the problem with this is that developers would still have to look at it for 
an overview (the volunteers would still need to copy the developers when they 
create a new bug)

the cyrus mail server will scale well for this sort of thing, and I beleive that 
it can also export the mailboxes as news feeds as well (I haven't ever 
configured this so I can't say the exact details)

for searching, just make it available to google (I'm sure google would cooperate 
with this sort of thing to find the best way to do it)

the key is to find people to volunteer to do the sorting. the hosting of this is 
pretty simple (for that matter, I'll offer to host it if nobody else steps up)

David Lang

> Hell, you could store them in a git tree if it came to it.
> That would also solve the problem for those with an aversion
> to web browsers to see bugs :-)

git is not particulary good for searching the contents of things.

on that note, I wonder if google has a git:// search as part of theit git code 
project? if not they should.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/