Sorry, not Andrew. DavidN.
Andrew argued the other way (quality->slower), which I also happen to not
necessarily believe in, but that's a separate argument.
Nobody should ever argue against raising quality.
The question could be about "at what cost"? (although I think that's not
necessarily a good argument, since I personally suspect that good quality
code comes from _lowering_ costs, not raising them).
But what's really relevant is "how?"
Now, we do know that open-source code tends to be higher quality (along a
number of metrics) than closed source code, and my argument is that it's
not because of bike-shedding (aka code review), but simply because the
code is out there and available and visible.
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!
Linus
--
