Re: [RFC][PATCH] Update REPORTING-BUGS

[Adrian Bunk <bunk@kernel.org>]

On Mon, Nov 26, 2007 at 01:51:37AM +0100, Rafael J. Wysocki wrote:
> On Monday, 26 of November 2007, Adrian Bunk wrote:
> > On Mon, Nov 26, 2007 at 01:04:25AM +0100, Rafael J. Wysocki wrote:
>...
> > > No, it doesn't, as long as the bug reports reach the right place.  Now, the
> > > question is what's that.
> > > 
> > > IMO, ideally, for each subsystem there should be a mailing list to send bug
> > > reports to.  The Bugzilla should forward the reports to these lists.  On every
> > > such list there should be (at least) one person responsible for responding to
> > > the bug reports, if no one else responds first, and for forwarding the reports
> > > to the appropriate developers.  This person should also be responsible for
> > > monitoring the status of each bug report sent to his/her list.
> > 
> > After all discussions about crazy bug tracker features we are back at 
> > the real problem:
> 
> We started to discuss them, because you argued that the Bugzilla in its current
> shape was sufficient, which I didn't agree with and tried to give some
> arguments.

The only real problem with the Bugzilla in it's current shape is that 
some developers do not use it.

> > Where do we find the tree these people grow on?
> 
> That's a good question, but either we find these people, or we'll start losing
> users at growing rates.
> 
> I'm afraid that's already happening ...

Agreed.  :-(

> > > _Every_ bug report sent (including invalid ones) should be recorded in a bug
> > > tracking system (be it the Bugzilla or whatever else) along with all of it's
> > > history (at least, refernces to the bug's history should be stored), no matter
> > > how it's been handled.  Moreover, a bug can only be resolved as "fixed" if
> > > there's a pointer to the exact commit fixing it in the bug's history.
> > 
> > And back we are at crazy bug tracker features...
> 
> No, they are not bug tracker features, but parts of a process that I think we
> should have in place.

The only real problem in our process is how to get reported bugs fixed.

Trying to define some peripheral process things when _the_ central part 
of the process is missing simply doesn't make much sense.

> > > > The only thing that matters is that we get bug reports resolved within a 
> > > > reasonable amount of time.
> > > 
> > > I'm not sure if that's generally possible:
> > > - What about the bugs that take 2 weeks or more to reproduce?
> > > - What about the bugs that we _don't_ _know_ how to fix?
> > 
> > We will never get 100% of all bugs fixed.
> > 
> > Let's get back to the fact that we have many bug reports that could be 
> > fixed within a reasonable amount of time but are not.
> 
> Do you have specific examples?

Take e.g. #3938 or #4039 as examples.

Both are quite different, but both should be fixable within < 1 month. [1]

> Rafael

cu
Adrian

[1] bugs like #4039 might be easier to debug now that git has been 
    written, but even without biseting it should be solvable

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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