Re: 2.6.19 -mm merge plans

[Jan Engelhardt]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/