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 yes, that help
can quite possibly be in the form of "process" - by making things more
streamlined, and by having people not have to waste time on wondering
where they should send things etc.
But the notion that we should even _try_ to aim to slow things down, that
one I find unlikely to be true, and I don't even understand why anybody
would find it a logical goal?
Of course, you will have fewer new bugs if you have fewer changes. But
that's not a goal, that's a tautology and totally uninteresting. A small
program is likely to have fewer bugs, but that doesn't make something
small "better" than something large that does more.
Similarly, a stagnant development community will introduce new bugs more
seldom. But does that make a stagnant one better than a virbrant one? Hell
no.
So what I'm arguing against here is not that we should aim for worse
quality, but I'm arguing against the false dichotomy of believing that
quality is incompatible with lots of change.
So if we can get the discussion *away* from the "let's slow things down",
then I'm interested. Because at that point we don't have to fight made-up
arguments about something irrelevant.
Linus
--
