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:	Thu, 1 May 2008 07:50:46 +0200
From:	Willy Tarreau <w@....eu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	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 Wed, Apr 30, 2008 at 06:19:56PM -0700, Linus Torvalds wrote:
> 
> 
> 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.

Note that I'm not necessarily arguing for slowing down, but for reduced
functional conflicts (which slow down may help but it's not the only
solution). I think that refining the time resolution might achieve the
same goal. Instead of merging 10000 changes which each have 1% chance
of breaking any other area, and have all developers try to hunt bugs
caused by unrelated changes, I think we could do that in steps.

To illustrate, instead of changing 100 areas with one of them causing
breaking in the other ones, and having 100 victims try to hunt the
bug in 99 other areas, then theirs, and finally insult the faulty
author, we could merge 50 areas in version X and 50 in X+1 (or 3*33
or 4*25, etc...). That way, we would only have 50 victims trying to
find the bug in 49 other areas (or 32 or 24). Less people wasting
their time will mean faster validation of changes, and possibly
faster release cycle with better quality.

People send you their crap every two months. If you accept half of
it every month, they don't have to sleep on their code, and at the
same time at most half of them are in trouble during half the time
(since bugs are found faster).

> 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.

well, is "let's split changes" ok ?

> 			Linus

Willy

--
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/