linux-kernel - Re: 2.6.19 -mm merge plans

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]

Message-ID: <Pine.LNX.4.64.0609202217420.4388@g5.osdl.org>
Date:	Wed, 20 Sep 2006 22:23:15 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Andrew Morton <akpm@...l.org>
cc:	Jeff Garzik <jeff@...zik.org>, linux-kernel@...r.kernel.org
Subject: Re: 2.6.19 -mm merge plans

On Wed, 20 Sep 2006, Andrew Morton wrote:
> 
> Why would a shorter cycle be better?  What are we trying to achieve?

I don't think a shorter cycle is necessarily better, but I think we could 
try having a more "directed" cycle, and perhaps merge certain specific 
things rather than everything.

That would possibly _cause_ a shorter cycle, if only because the problems 
are hopefully more focused from the fact that we merged with a certain 
focus.

Of course, it would likely just frustrate the people who didn't get 
merged, and would need to wait for the next cycle. So it might be a net 
negative, even if we'd bring individual cycles in a bit.

> > The cycles seem to be stretching out again, and I don't really think 
> > it's worth it to hold up the entire kernel for every single piddly 
> > little regression to get fixed.  We'll _never_ be perfect, even if we 
> > weren't slackers.

I think that's true. 2.6.18 got delayed partly due to me beign away, but I 
also think that it then got delayed too much afterwards too, just because 
I felt a bit nervous about having been away ;)

So it definitely stretched out too much.

Whether there is a lot we can do about it, I dunno. In many ways, the real 
issue is simply that we have a lot of changes. And people are _never_ as 
interested in the testing part as they were in writing new code..

		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/