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]

Date:	Thu, 21 Sep 2006 17:50:40 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Linus Torvalds <torvalds@...l.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Andrew Morton <akpm@...l.org>,
	Jeff Garzik <jeff@...zik.org>, linux-kernel@...r.kernel.org
Subject: Re: 2.6.19 -mm merge plans

On Sep 21 2006 08:25, Linus Torvalds wrote:
>
> - 2.6.<odd> is "the big initial merges with all the obvious fixes to make 
>   it all work" (ie roughly the current -rc2 or perhaps -rc3).
>
> - 2.6.<even> is "no big merges, just careful fixes" (ie the current "real 
>   release")

That sounds interesting. To me this looks like a careful approach at 
more or less marking a release "this contains new stuff" and "this does 
not", like 2.<odd>.x and 2.<even>.x, respectively, but of course without 
the code divergence that happened between 2.4 and 2.5.

Will there be a -stable branch for 2.6.<odd>s, or will they be limited 
to 2.6.<even>, just like there is no -stable for -rcs?

>Each would be ~3 weeks, leaving us with effectively the same real release 
>schedule, just a naming change.

More or less, yes. Let's assume a "good release" (one with a fair number 
of -rcs), and compare both approches (hope your MUA does tabs=8):

Week/Current	Current style	Week/Proposal	Your proposal
+0		2.6.18		+0		2.6.18
+2		2.6.19-rc1	-		none
+3		2.6.19-rc2	+3		2.6.19
+4		2.6.19-rc3	-		none
+5		2.6.19		+6		2.6.20
+7		2.6.20-rc1	-		none
+8		2.6.20-rc2	+9		2.6.21
+9		2.6.20-rc3	-		none
+10		2.6.21		+12		2.6.22
(+1 between each -rc is purely assumptional)

Though this is a purely dry mathematical table. We did not always stick 
to a "-rc3 at most" rule, but gone up to like -rc7 recently. With the 
new versioning scheme, no such thing seems likely to be happening 
(excluding of course external influences like people travelling).
IOW, the schedule gets more organized. I like that idea.

(Based upon the assumption that 1 week passes between each -rc 
release, there would, with the new proposal, 'only' be 243 weeks to hit 
2.6.99 instead of 405. That is, version numbers go up faster :)

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