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] [day] [month] [year] [list]

Message-Id: <200807201753.48252.v13@v13.gr>
Date:	Sun, 20 Jul 2008 17:53:47 +0300
From:	Stefanos Harhalakis <v13@....gr>
To:	Rene Herman <rene.herman@...access.nl>
Cc:	Craig Milo Rogers <rogers@....edu>,
	Jan Engelhardt <jengelh@...ozas.de>,
	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 Sunday 20 July 2008, Rene Herman wrote:
> On 19-07-08 22:49, Craig Milo Rogers wrote:
> > On 08.07.19, Rene Herman wrote:
> >> Really, find me a single Linux developer who wouldn't try just a little
> >> bit harder for a big 3.0 release. This is still a community, not yet a
> >> boring office schedule...
> >
> > 	I'm afraid that the allure of 3.0 would mean that everyone
> > would want to get their shiny new subsystem/scheduler
> > rewrite/bootstrap file format change/whatever incorporated into it,
> > resulting in a protracted integration period and an unstable system.
> > According to this line of thought, Linus should simply announce
> > version 3.0 with no forewarning...
>
> Or better yet, we'd have 342 -rc's and a REALLY big party when 3.0
> finally hits the streets.

I suggest that major and minor versions follow some milestones (as suggested 
to a message that I cannot reply directly). For example:

Starting from 'today', mark all open bugs and change version to 2.7 when all 
those bugs are closed. Then mark the open bugs of that time and change to 2.8 
when those bugs are fixed. Repeat as needed.

Set a 'target'/goal and change version to 3.0 whenever worldwide linux 
server/desktop percentage reaches XX%. (Of course this may happen before 
changing to 2.7 but this is not a bad thing (tm)). Then set another target 
(that may not be related to linux adoption) etc, etc...

This will keep the current versioning scheme, set some common goals for all 
developers, add more meaning into trying to fix bugs and prevent the world
from experiencing large linux version numbers.

As a side-effect, setting targets like those may make the whole community 
cooperate even more/better by having common long-term goals.

...

p.s You could also keep the X.Y.Z notation and change the major version
number whenever the way of versioning changes (and the current one is
actually version 2) :P
--
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/