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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110524020135.GA19249@elte.hu>
Date:	Tue, 24 May 2011 04:01:35 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Ted Ts'o <tytso@....edu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arch@...r.kernel.org, DRI <dri-devel@...ts.freedesktop.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>
Subject: Re: (Short?) merge window reminder

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> Another advantage of switching numbering models (ie 3.0 instead of
> 2.8.x) would be that it would also make the "odd numbers are also
> numbers" transition much more natural.

Yeah, it sounds really good to get rid of the (meanwhile) meaningless
"2.6." prefix from our version code and iterate it in a more
meaningful way.

I suspect the stable team and distros will enjoy the more meaningful
third digit as well: it will raise the perceived importance of
stabilization and packaging work.

Btw., we should probably remove the fourth (patch) level, otherwise
distros might feel tempted to fill it in with their own patch-stack
version number, which would result in confusing "3.3.1.5" meaning
different things on different distros - while 3.3.1-5.rpm style of
distro kernel package naming denotes the distro patch level more
clearly.

I don't think the odd/even history will linger too long: in practice
we'll iterate through 3.1, 3.2, 3.3 and 3.4 rather quickly, in the first
year, so any residual notion of stable/unstable will be gone within a
few iterations.

> Because of our historical even/odd model, I wouldn't do a 2.7.x -
> there's just too much history of 2.1, 2.3, 2.5 being development
> trees. But if I do 3.0, then I'd be chucking that whole thing out the
> window, and the next release would be 3.1, 3.2, etc..
> 
> And then in another few years (probably before getting close to 3.40,
> so I'm not going to make a big deal of 3 = "third decade"), I'd just
> do 4.0 etc.

Perhaps we could do 4.0 once the last bit of -rt hits upstream? /me ducks

> Because all our releases are supposed to be stable releases these
> days, and if we get rid of one level of numbering, I feel perfectly
> fine with getting rid of the even/odd history too.

They are very stable releases as far as i'm concerned - i can pretty
confidently run and use -rc2 and better kernels on my boxes these days
and could do so for the past few years.

Thanks,

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