Date:	Wed, 30 Apr 2008 14:37:27 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>
Subject: Re: Slow DOWN, please!!!



On Wed, 30 Apr 2008, Rafael J. Wysocki wrote:
> > 
> >    Long merge windows don't work - because rather than test more, it just 
> >    means that people will use them to make more changes!
> 
> And what do you think is happening _after_ the merge window closes, when
> we're supposed to be fixing bugs?  People work on new code.  And, in fact, they
> have to, if they want to be ready for the next merge window.

Oh, I agree. But at that point, the issue you brought up - of testing and 
then having the code change under you wildly - has at least gone away.

And I think you are missing a big issue:

> Sorry to say that, but I don't think this is realistic.  What happens after the merge
> window is people go and develop new stuff.

>From a testing standpoint, the *developers* aren't ever even the main 
issue. Yes, we get test coverage that way too, but we should really aim 
for getting most of the non-obvious issues from the user community, and 
not primarily from developers.

So the whole point of the merge window is *not* to have developers testing 
their code during the six subsequent weeks, but to have *users* able to 
use -rc1 and report issues!

That's why the distro "testing" trees are so important. And that's why 
it's so important that -rc1 be timely. 

> My point is, given the width of the merge windown, there's too much stuff
> going in during it.  As far as I'm concerned, the window can be a week long
> or whatever, but let's make fewer commits over a unit of time.

I'm not following that logic. 

A single merge will bring in easily thousands of commits. It doesn't 
matter if the merge window is a day or a week or two weeks, the merge will 
be one event.

And there's no way to avoid the fact that during the merge window, we will 
get something on the order of ten thousand commits (eg 2.6.24->25-rc1 was 
9629 commits).

So your "fewer commits over a unit of time" doesn't make sense. We have 
those ten thousand commits. They need to go in. They cannot take forever. 
Ergo, you *will* have a thousand commits a day during the merge window.

We can spread it out a bit (and I do to some degree), but in many ways 
that is just going to be more painful. So it's actually easier if we can 
get about half of the merges done early, so that people like Andrew then 
has at least most of the base set for him by the first few days of the 
merge window.

So here's the math: 3,500 commits per month. That's just the *average* 
speed, it's sometimes more. And we *cannot* merge them continuously, 
because we need to have a stabler period for testing. And remember: those 
3,500 commits don't stop happening just because they aren't merged. You 
should think of them as a constant pressure.

So 3,500 commits per month, but with a stable period (that is *longer* 
than the merge window) that means that the merge window needs to merge 
that constant stream of commits *faster* than they happen, so that we can 
then have that breather when we try to get users to test it. Let's say 
that we have a 1:3 ratio (which is fairly close to what we have), and that 
means that we need to merge 3,500 commits in a week. 

That's just simple *math*. So when you say "let's make fewer commits over 
a unit of time" I can onyl shake my head and wonder what the hell you are 
talking about. The merge window _needs_ to do those 3,500 commits per 
week. Otherwise they don't get merged!

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists