On Monday, 30 April 2007 00:00, Adrian Bunk wrote:
quoted text
> On Mon, Apr 30, 2007 at 12:00:28AM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 29 April 2007 22:43, Adrian Bunk wrote:
> > > On Sun, Apr 29, 2007 at 10:18:10PM +0200, Rafael J. Wysocki wrote:
> > > >...
> > > > 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.
> > > >...
> > > 
> > > How can I get the functionality "show me all unfixed SATA bugs"?
> > > 
> > > That's one of the important functionalities of every bug tracking 
> > > system.
> > 
> > That's the missing piece, obviously.
> > 
> > BTW, I didn't want to say that one could entirely replace a bug-tracking system
> > with tracking the LKML archives.  What I wanted to say was that the email
> > messages sent to the LKML were easily trackable and could be hooked up into a
> > bug-tracking system, for example with the help of URLs.
> > 
> > In such a setup people could send initial reports to the LKML and the links to
> > these messages might be put into a bug-tracking system as soon as it turned
> > out that the bugs were worthy of tracking.
> 
> Who is doing this "might be put", and why don't you start with asking 
> the submitter to submit bugs in a bug tracking system and forward the 
> bug report from the bug tracking system (manually or automatically) to 
> the developers and linux-kernel?

Because quite often I know what the problem is after having asked the reporter
a couple of simple questions or I can forward his report to a list on which
there are the right people and the problem gets fixed quickly, so it just
doesn't need to be formally registered.

The problem with the bugzilla is that it requires a considerable setup for each
bug which is a loss of time if the bug is trivial.  Using the bugzilla for
handling trivial bugs just doesn't make sense, IMHO.  It's too heavywieght
for that.  [It _is_ useful nevertheless.  For example, the suspend metabug that
you've created for me is really a nice thing, so thanks a lot again. :-)
Perhaps something like this might be used for tracking the regressions ...]

Unfortunately, you can't say whether or not the bug is trivial until you see
the report.  If you've got it from bugzilla, you're stuck with it, so it's just
more efficient to use something else in the initial phase of resolving
problems.

Greetings,
Rafael
-
unsubscribe notice
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/