Re: Slow DOWN, please!!!

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 30 Apr 2008 21:36:57 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Wednesday, 30 of April 2008, David Miller wrote:
> > 
> > This is starting to get beyond frustrating for me.
> > 
> > Yesterday, I spent the whole day bisecting boot failures
> > on my system due to the totally untested linux/bitops.h
> > optimization, which I fully analyzed and debugged.
> > 
> > Today, I had hoped that I could get some work done of my
> > own, but that's not the case.
> > 
> > Yet another bootup regression got added within the last 24
> > hours.
> > 
> > I don't mind fixing the regression or two during the merge
> > window but THIS IS ABSOLUTELY, FUCKING, REDICULIOUS!
> > 
> > The tree breaks every day, and it's becomming an extremely
> > non-fun environment to work in.
> > 
> > We need to slow down the merging, we need to review things
> > more, we need people to test their fucking changes!
> 
> Well, I must say I second that.

ooh, fun thread.

One of the main reasons for -mm (probably _the_ main reason) is to weed out
other-developer-impacting regressions before they hit mainline and, umm,
affect developers.

But there are implementation problems:

a) developers aren't testing -mm enough

b) -mm releases have become too slow, and (hence) too unstable

c) people are slamming changes into mainline which have never been seen
   in -mm.  Lots of changes.

So here's how we're going to fix David's problem:

- Everyone gets their stuff into linux-next.

- Lots of people _test_ linux-next.  Just once a week.

Those two steps will improve the merge-window chaos a lot.  Things will get
better.




The remaining open problem is what do we do about the shiny new code which
is getting slammed into the merge window?

Well, it's very easy to tell whether code which appears in the merge window
was present in linux-next.

Our first way of preventing people from shoving inadequately-cooked code
into the merge window is suasion (aka flaming their titties off).  If that
proves insufficient and if we still have a sufficiently large problem that
we need to do something about it then sure, let's reevaluate.

But one thing at a time.  For the 2.6.27 release let us concentrte on two
things

- get your stuff into linux-next

- test linux-next.

If merge-window stability is still a problem after that then let's revisit?