Re: Linux 2.6.21

[Rafael J. Wysocki]

On Sunday, 29 April 2007 21:14, Andi Kleen wrote:
> On Sun, Apr 29, 2007 at 08:50:55PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 29 April 2007 19:37, Andi Kleen wrote:
> > > > My personal experience with bugzilla is that it's very unfriendly to
> > > > reporters.  IMHO it's suitable for tracking unresolved problems along with
> > > > debug patches, system information etc., but not for _reporting_ new ones.
> > > 
> > > What did you find unfriendly? 
> > 
> > - You are required to select a category and 'component' for your report, which
> > often is difficult (especially if you're not a kernel expert)
> 
> Usually there is other and then someone else figures it out.
> 
> > - You need to have a bugzilla account (or to create one, if you don't)
> > - If you want to add an address to the CC list, it must be known to bugzilla
> > and there's no (obvious) way to check which addresses are known (bugzilla
> > rejects the report if there's a 'wrong' email address in the list)  [IMO this is
> > really really broken.]
> 
> The Novell bugzilla actually has that fixed. You have a search email button
> to look up addresses.  Perhaps that feature will be ported someday into
> the kernel.org one (I would like to have it too) 
> 
> > - You are asked to provide many details that need not be relevant and casual
> > reporters don't know that they can skip this part
> > - Attaching files is tedious and referring to attachments unintuitive
> 
> Anyways that are mostly all detail (except the registration requirement) that
> could be probably all easily fixed.
> 
> > And I think they are two _totally_ conceptually different things.  You report
> > a bug to let somebody know that there's a problem and this doesn't necessarily
> 
> The problem is we need a way to route those reports to the right people.
> Routing it to a single person or broadcasting it just doesn't scale.
> And the best way I know of is to use some database that keeps track of the state.
> 
> That is what bugzilla is essentially.
> 
> > For this reason there should be a simple means of filing initial bug reports
> > with someone to look at them and forward them to appropriate people who will
> > decide if the problem needs to be tracked.  If they do, it's time to use
> > bugzilla.  Not earlier.
> 
> The only sane way to do that would be to save them somewhere and keep
> a list and then let a group of people process them.

But emailed reports _are_ saved anyway and we _know_ how to get a copy.
>From lkml.org, for example.  Why don't we use that?  The only missing piece
is the 'keep a list' thing, but that's not a rocket science, IMHO.

[For example, you can create a bugzilla entry with a link to the lkml.org copy
of the relevant message, so why to require the reporter to file the report with
the bugzilla himself?]

_Moreover_, some LKML archives, for example at http://marc.info/?l=linux-kernel,
keep track of each thread separately, so you can browse any of them at any
time.  In particular, you can see the _history_ of each bug report sent to LKML
if you have a link to any message in its thread.

Really, if we ask reporters to put '[BUG]' in the subjects of their messages,
you'll even be able to use the lkml.org archives plus wget and a couple of
shell scripts to cherry pick the links to all bug reports sent to the list
within a given time interval.

All of this functionality is out there already.

> Hmm, wait... sounds like bugzilla, doesn't it?
> 
> > You are right, email is not suitable for tracking bugs.

Well, now, I think that even this statement is not exactly right. :-)

> > Still, it works quite well as a means of sending initial reports.
>
> I disagree. It works small scale but does not really scale well.

IMO that depends on how you handle it.

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