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!
DZone has just released the first set of their 
![[x]](http://norman.walsh.name/2008/03/04/examples/delete.gif)
![[+]](http://norman.walsh.name/2008/03/04/examples/right.gif)
![[L]](http://norman.walsh.name/graphics/linkgroup.gif)
![[-]](http://norman.walsh.name/2008/03/04/examples/down.gif)
![[image]](http://www.russellbeattie.com/blog/media/mowserdotmobi.png)