On Sunday, 17 June 2007 12:22, Michal Piotrowski wrote: > On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski <[EMAIL PROTECTED]> > > 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.
Except when the bisection points us to a patch exposing a bug that is present regardless (see http://lkml.org/lkml/2007/6/13/273 for example). Besides, if a patch is merged before -rc1 as a bugfix, there are several patches depending on it and only after -rc5 has been released we find out that it breaks someone's system, then reverting it is not a solution, IMO. > > 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. People should test _all_ of the -rc kernels and report problems. Otherwise, we may assume that there are no problems and go on. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/