linux-kernel - Re: (Short?) merge window reminder

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110525044718.GA4647@bench>
Date:	Wed, 25 May 2011 00:47:18 -0400
From:	porpen <porpen@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: (Short?) merge window reminder

Hi,

On Mon, May 23, 2011 at 12:13:29PM -0700, Linus Torvalds wrote:
> PS. The voices in my head also tell me that the numbers are getting
> too big. I may just call the thing 2.8.0. And I almost guarantee that
> this PS is going to result in more discussion than the rest, but when
> the voices tell me to do things, I listen.

With all the discussion about matching the year, keeping the numbers smallish and breaking build/test scripts...

Why not match the year this way: v2.11 = 2011

So, to get there, how about: 
v2.6.39 current
v2.6.40 
v2.7.?  (see below)
v2.11.0 sometime this year maybe or skipped.
v2.12.? early 2012.
v2.13.? early 2013.
and so on...

To hell with making the months match up to anything.  IMHO, that's micromanaging BS that will cause recurring troubles forever.

Advantages: 
 -Build & test scripts won't break for a while. (see note about this below)
 -Major and Minor numbers together approximately match the year of release.
 -Subreleases don't get too big. e.g. with 2 week releases, v2.12.x might reach .26 or .27 and resets with v2.13.0 

Disadvantages:
 -in the year 2100 the version will have to leap to v21.0 and that numbering will last until v29.99 or so.
 -most of us won't live long enough to see v31.14 or v42.0

The build scripts would finally break in the year 25500 with the step after kernel v254.99.?.  I suspect one of our decendants in the next 23.5 thousand years can figure out how to fix that.

IMHO, this may be a least effort compromise between the keep-numbers-small camp, the match-the-year camp and the don't-break-scripts camp.

Of course, math junkies like me would love to see v2.7.18.28 at some point in the process.  Could we jump straight to that just before we leap to v2.11.0 or whatever numbering is chosen please?

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