After the merge window closed...

By Jonathan Corbet
March 16, 2010

Toward the end of the 2.6.33 development cycle, Linus suggested that he might make the next merge window a little shorter than usual. And, indeed, 2.6.34-rc1 came out on March 8, twelve days after the 2.6.33 release. A number of trees got caught out in the cold as a result of that change, and that appears to be a result that suits Linus just fine.

That said, some trees have been pulled after the -rc1 release. These include the trivial tree, with the usual load of spelling fixes and other small changes. There was a large set of ARM changes, including support for a number of new boards and devices. The memory usage controller got a new threshold feature allowing for finer-grained control of (and information about) memory usage. And so on; all told, nearly 1,000 changes have been merged (as of this writing) since the 2.6.34-rc1 release.

When the final SCSI pull request came along, though, Linus found his moment to draw a line in the sand. Linus, it seems, is getting a little tired of what he sees as last-minute behavior from some subsystem maintainers:

I've told people before. The merge window is for _merging_, not for doing development. If you send me something the last day, then there is no "window" any more. And it is _really_ annoying to have fifty pull requests on the last day. I'm not going to take it any more.

So, Linus says, he plans to be even more unpredictable in the future. Evidently determinism in this part of the process leads to behavior he doesn't like, so, in the future, developers won't really be able to know how long the merge window will be. In such an environment, most subsystem maintainers will end up working as if the merge window had been reduced to a single week - an idea which had been discussed and rejected at the 2009 Kernel Summit.

Index entries for this article
Kernel	Development model

After the merge window closed...

Posted Mar 18, 2010 4:23 UTC (Thu) by thedevil (guest, #32913) [Link] (2 responses)

I know this is ridiculous, but I am reminded of the TSA policy of explicit unpredictability after the xmas day Detroit attack.

And it *does* feel arrogant, in the same way.

After the merge window closed...

Posted Mar 18, 2010 6:41 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

It's probably not really that big of a deal though.

Nobody really uses Linus's tree directly anymore. At least the number of folks that do it are
relatively small.

People use distro-supplied kernels nowadays and if a distro decides to use a Linus branch kernel
directly on it's first 'release' does not really deserve to have users due to their obvious stupidity.

After the merge window closed...

Posted Mar 18, 2010 7:32 UTC (Thu) by dlang (guest, #313) [Link]

if the maintainers don't have their trees ready prior to th emerge window, how much testing do those trees actually get prior to being merged?

Linus has made the same point about trees that get re-based immediately prior to to the pull request.

I suspect that by delaying such trees to the next merge window the tree will stabilize faster and end up shortening the time until the next full release.

After the merge window closed...

Posted Mar 18, 2010 10:03 UTC (Thu) by dgm (subscriber, #49227) [Link] (2 responses)

Can someone explain why is a one-day merge window a bad thing? Would it not work to have all maintainers asking Linus to merge the first day, even if the merge process proper took several days?

After the merge window closed...

Posted Mar 18, 2010 14:50 UTC (Thu) by jengelh (subscriber, #33263) [Link] (1 responses)

Because someone is always on a business trip just that very moment, or something else. Mind you that travelling long distance (e.g. Tokyo--Paris) already takes 13 hours of the so-proposed merge day.

After the merge window closed...

Posted Mar 18, 2010 19:42 UTC (Thu) by iabervon (subscriber, #722) [Link]

I think the answer there may be a bit of queuing; let maintainers send in pull requests for future releases (fixing the contents of the pull) during the -rc7 or so timeframe, and just send reminders after. It obviously does nobody any good to test the reflexes of the maintainers.

In the SCSI tree's case, there's the odd situation of the maintainer having a set of changes together slightly after the start of the merge window, as a result of getting pull requests in response to the release of the previous version. The maintainer was holding off on sending these on to Linus in order to try to get them some more exposure in -next before sending them to Linus. The proper procedural change may be more on the side of telling Linus (early) that there's something baking in -next, and let Linus put off merging it until it's more baked or skip it if it's not testing well.