linux-kernel - Re: From 2.4 to 2.6 to 2.7?

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: <200807151518.59338.info@gnebu.es>
Date:	Tue, 15 Jul 2008 15:18:58 +0200
From:	Alberto Gonzalez <info@...bu.es>
To:	Kasper Sandberg <lkml@...anurb.dk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Stoyan Gaydarov <stoyboyker@...il.com>,
	linux-kernel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
	gorcunov@...il.com, akpm@...ux-foundation.org, mingo@...e.hu
Subject: Re: From 2.4 to 2.6 to 2.7?

On Tuesday 15 July 2008, Kasper Sandberg wrote:
> I like the current numbering fine.. my suggestion is to keep the current
> model, there are various reasons
>
> 1: it requires no effort
> 2: various things doesent break
> 3: naming isnt _THAT_ important

Sorry for entering a discussion from a project I'm just a user of, but I was 
thinking... I do see smallish problems with current scheme:

- First two numbers never change (2.6), so they're mostly useless.
- Third number gets too big (currently 26, and growing)
- Stable releases are already a fourth number (2.6.25.11. Unconfortable).

So a possible solution that would not break completely with historical numbers 
could be:

- Since you're aproaching 2.6.30 (around mid 2009), why not agree tu turn that 
into a 3.0 release? Peope have been expecting a version 3 of the kernel for a 
long time now... It might give the (false) impression that it's an all new 
release, but it would be explained that it's just a normal one. However, I 
also think that by that time, the last "problem" with Linux will be solved, 
i.e, the graphics thing. With the changes in DRM/DRI starting to appear in 
2.6.27 (maybe), they will stabilize through .28 and .29, making .30 a good 
release to declare the Linux kernel "completely mature", without any weak 
spot (so to say) and turn it into 3.0 release (the Free drivers for ATI and 
even NVIDIA will hopefully be mature by then too, as might be Gallium3D, 
VA-API, GEM/TTM, etc... )

- From there, how to proceed? Instead of making the same mistake again of 
having a useless middle number, each release would increment by a 10th. That 
is, instead of 3.0.1, 3.0.2, etc... just 3.1, 3.2, 3.3, etc... Then the stable 
releases would be 3.1.1, 3.1.2, etc... (no longer a 4 series of numbers). And 
after 3.9, we would have 4.0 to avoid having again a too bit number (3.26, 
etc...). Roughly, you release 5 kernels per year, so that would give enough 
time until you hit a high number (it will increment by one every two years). 
For example, it would take 20 years from 2009 until you hit version 13.0. 
Twenty years is a decent amount of time in kernel development. And well, even 
13 is not _that_ big anyway. You can push this numbering up to version 20 if 
necessary and that would give another 14 extra years. By then (year 2043) I'm 
sure that someone will have come up with a smart way of rearranging the 
numbering once more :-)

Regards.

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