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!