eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Before now, if developers were contributing to the Linux kernel, were late getting the code in, it wasnt 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 wouldnt 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 hed 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.
“Im hoping there arent any infrastructure upheavals that break drivers again, because if there are, I think were 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 Ill just make sure that I dont always merge on the last day or two.”
Bottomley replied, “Thats a nice theory, except that its 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 wasnt 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 its their code that gets delayed, not yours.”
The reason for this harder line is simple.
“If youre 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 hes changing how Linuxs development rules are being enforced.
He continued, “And trust me, I will say that. People always complain that Im 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), Ill just refuse to merge, and laugh in their faces derisively when they whine plaintively at me, and tell them theres 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.
Check out eWEEK.coms for the latest open-source news, reviews and analysis.