Before now, if developers were contributing to the Linux kernel, were late getting the code in, it wasn't a big deal. Chances were it would be squeezed in anyway. That was then. This is now.

Recently on the Linux Kernel Mailing List, the online working group for kernel development, an all too typical case of code being delivered late for the next merge into the next testing version of the operating system occurred.

In this particular case, several SCSI developers were not turning in their code with enough time for sufficient testing to make sure that the new code wouldn't break anything.

Because of the lateness of the submissions, James Bottomley, CTO of Steeleye Technology Inc., a high-availability and disaster recovery company, and the Linux Kernel SCSI Maintainer, requested that he'd like to "regression test it for a day or two, so I plan to request the final merger on Friday," into the new test Linux kernel.

This drew a response from Linus Torvalds, who has recently been emphasizing that for the sake of efficient development and keeping Andrew Morton, another leading Linux developer who oversees bug-fixing, from burning out, close to finished code must be turned in during a two week period, before going into a four week test cycle.

"I'm hoping there aren't any infrastructure upheavals that break drivers again, because if there are, I think we're going to have to make a separate rule for things like that: they have to be merged early in the sequence or not at all," wrote Torvalds.

Torvalds added, In general I find it very wrong to consciously leave the merge until the last day of the merge window."

Therefore, "If that keeps happening, I think I'll just make sure that I don't always merge on the last day or two."

Bottomley replied, "That's a nice theory, except that it's my contributors who drop me in it by leaving their patch sets until you declare a kernel, dumping the integration testing on me in whatever time window is left."

Torvalds wasn't impressed. "If your sub-maintainers keep screwing you, then you tell them to stop it, and stop accepting their patches in that window, so that it's their code that gets delayed, not yours."

The reason for this harder line is simple.

"If you're doing the development during the merge window, not only do you get in late in the window, you also do a hurried job and thus almost certainly have a worse process," said Torvalds.

"The whole point of having timely merge windows is that we can just say 'sorry, you missed the bus, wait for the next one.'

Torvalds is quite aware that he's changing how Linux's development rules are being enforced.

He continued, "And trust me, I will say that. People always complain that I'm being too soft. Not so this time. If people miss the merge window or start abusing it with hurried last-minute things that just cause problems for -rc1 (release candidate one), I'll just refuse to merge, and laugh in their faces derisively when they whine plaintively at me, and tell them there's going to be a new opening soon enough."

With the air cleared, the kernel development team discussed details on how to improve the Linux workflow to meet Torvalds' requirements. That being done, the developers have moved on to continue to work on the operating system.

This article was originally published on eWEEK.com.