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:
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.
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
--
