That is largely on purpose.
There's two choices:
- have a longer and calmer merge window, spread out the joy, and have
people test and fix their things during the merge window too. In other
words, less black-and-white.
- Really short merge window, and use the extra time *after* it to fix the
issues.
and I've obviously gone for the latter. In fact, I'd personally like to
make it even shorter, because the problem with the long merge window can
be summed up very simply:
Long merge windows don't work - because rather than test more, it just
means that people will use them to make more changes!
So one of the major things about the short merge window is that it's
hopefully encouraging people to have things ready by the time the merge
window opens, because it's too late to do anything later.
And yes, we could have some other way of enforcing that - allow the merge
window to be longer, but have some other mechanism to make sure that I
only merge old code.
In fact, I'd personally *love* to have a hard rule that says "I will only
pull from trees that were already 'done' by the time the window opened",
and we've been kind-of moving in that direction.
But that wish is counteracted by the fact that the merges themselves do
need some development, so expecting everything to be ready before-hand is
simply not realistic.
Also, while I'd like trees to be ready when the window opens, at the same
time I do think that it's good to spread out some of it, and get *some*
basic testing - even if it's just a nightly build and a few tens of
developers.
And really, that's all that we'd expect during the merge window. We want
to find the *obvious* problems - build issues, and the things that hit
everybody, but let's face it, the subtle ones will take time to find
regardless.
Then, the short merge window means that we have more time when we really
don't have big changes going in to find the subtle ones.
(And making the release cycle longer would *not* help - that would just
make the next merge window more painful, so while it can, and does, work
for some individual release with particular problems, it's not a solution
in the long run).
Linus
--
