Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

Rafael J. Wysocki
2007-06-17T12:07:11Z

On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
> On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:
> > On 17/06/07, Andrew Morton <akpm@linux-foundation.org> wrote:
> > >On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski
> > ><michal.k.k.piotrowski@gmail.com> wrote:
> > >
> > >> +If the patch introduces a new regression and this regression was not
> > >fixed
> > >> +in seven days, then the patch will be reverted.
> > >
> > >Those regressions where we know which patch caused them are the easy ones.
> > >Often we don't know which patch (or even which subsystem merge) is at
> > >fault.
> > >
> > >I think. How many of the present 2.6.22-rc regressions which you're
> > >presently tracking have such a well-identified cause?
> > >
> >
> > Here lays the problem.
> >
> > git-bisect is a killer app, people should start using it.
>
> It's OK _only_ in case of unknown, hard to find *hardware* bugs.
>
> If you think it's "a good thing" for bad, untested by developer
> code, then something is completely wrong.

Oh, I've just fixed two purely software bugs pointed out by binary searching
in the code that I'm sure has been tested, not only by its developers, but the
bugs only showed up in my configuration (on one out of four test boxes).

There are so many different kernel configurations possible that there's no way
a developer can test them all.

Greetings,
Rafael

--
"Premature optimization is the root of all evil." - Donald Knuth