Re: RFD: Kernel release numbering

[Lars Marowsky-Bree <lmb@suse.de>]

On 2005-03-02T14:21:38, Linus Torvalds <torvalds@osdl.org> wrote:

> We'd still do the -rcX candidates as we go along in either case, so as a 
> user you wouldn't even _need_ to know, but the numbering would be a rough 
> guide to intentions. Ie I'd expect that distributions would always try to 
> base their stuff off a 2.6.<even> release.

If the users wouldn't even have to know, why do it? Who will benefit
from this, then?

I think a better approach, and one which is already working out well in
practice, is to put "more intrusive" features into -mm first, and only
migrate them into 2.6.x when they have 'stabilized'.

This could be improved: _All_ new features have to go through -mm first
for a period (of whatever length) / one cycle. 2.6.x only directly picks
up "obvious" bugfixes, and a select set of features which have ripened
in -mm. 2.6.x-pre releases would then basically "only" clean up
integration bugs.

-mm would be the 'feature tree'. Of course, features which have matured
in other eligible trees might also work; the key point is the two-stage
approach and it doesn't matter whether the chaos stage has one or three
trees, as long as it's not more than that.

I think that would be natural extension of how things already work and
just tightens the process some.


(From a vendor perspective, this would mean we'd be safe picking up any
2.6.x tree + select choices from x+1-pre plus whatever we are force fed
by those who pay.)

If one wanted to get fancy, which I'm throwing in just to make everybody
lose the core point of the argument: One could associate "points" with
each feature / patch in -mm, based on an estimation of how
intrusive/well-tested/dangerous/heavenly that patch is, and mandate that
only 42 points per 2.6.x release are allowed.

Of course, one could also apply common sense. But, that's not as silly.
Or way more so, but less amusing than voting wars.

> Comments?

The numbering scheme is more confusing and unclear, and complexity is
the enemy of reliability.



Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business