Boxes and Glue

From time to time it is fascinating to learn how the linux community deals with the Software Engineering processes involved when the development speeds is so damned fast as it is being for the linux kernel as of lately. This whole thread is very interesting. Linus hightlihts development as patch pressure:

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.

Later, when asked to slow down:

On Thu, 1 May 2008, Rafael J. Wysocki wrote:
> 
> > 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).
> 
> Well, do we _have_ _to_ take that much?  I know we _can_, but is this really
> necessary?
Do you want me to stop merging your code?
Do you think anybody else does?
Any suggestions on how to convince people that their code is not worth 
merging?

Another pearl of wisdom:

An example of this: I don't believe code review tends to much help in 
itself, but I *do* believe that the process of doing code review makes 
people more aware of the fact that others are looking at the code they 
produce, and that in turn makes the code often better to start with.

And this whole message:

Hey, guv, do you _honestly_ believe that some kind of ISO-9000-like 
process generates quality?
And I dislike how people try to conflate "quality" and "merging speed" as 
if there was any reason what-so-ever to believe that they are related.
You (and Andrew) have tried to argue that slowing things down results in 
better quality, and I simply don't for a moment believe that. I believe 
the exact opposite.
The way to get good quality is not to put barriers up in front of 
developers, but totally the reverse - by helping them.

And this one, for us, normal people, who are really slow:

And as a result of that, my personal belief is that the best way to raise 
quality of code is to distribute it. Yes, as patches for discussion, but 
even more so as a part of a cohesive whole - as _merged_ patches!
The thing is, the quality of individual patches isn't what matters! What 
matters is the quality of the end result. And people are going to be a lot 
more involved in looking at, testing, and working with code that is 
merged, rather than code that isn't.
So _my_ answer to the "how do we raise quality" is actually the exact 
reverse of what you guys seem to be arguing.
IOW, I argue that the high speed of merging very much is a big part of 
what gives us quality in the end. It may result in bugs along the way, but 
it also results in fixes, and lots of people looking at the result (and 
looking at it in *context*, not just as a patch flying around).
And yes, maybe that sounds counter-intuitive. But hey, people thought open 
source was counter-intuitive. I spent years explaining why it should work 
at all!

Keep on reading the thread, those linux kernel discussions are great software engineering!