linux-kernel - Re: Slow DOWN, please!!!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Apr 2008 18:19:56 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Willy Tarreau <w@....eu>, David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>
Subject: Re: Slow DOWN, please!!!

On Thu, 1 May 2008, Rafael J. Wysocki wrote:
> 
> > I do _not_ want to slow down development by setting some kind of "quality 
> > bar" - but I do believe that we should keep our quality high, not because 
> > of any hoops we need to jump through, but because we take pride in the 
> > thing we do.
> 
> Well, we certainly should, but do we always remeber about it?  Honest, guv?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/