Re: New dev model (was [PATCH] delete devfs)

[Ben Hoskings <ben@jeeves.gotdns.org>]

On Fri, 23 Jul 2004 09:01, Andrew Morton wrote:
> Well.  We'll see.  2.6 is becoming stabler, despite the fact that we're
> adding features.
>
> I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
> fixes against 2.6.20 if there is demand for it.  Anyone who really cares
> about stability of kernel.org kernels won't be deploying 2.6.20 within a
> few weeks of its release anyway, so by the time they doodle over to
> kernel.org they'll find 2.6.20.2 or whatever.

I'd like to throw my opinion into the discussion at this point too, for what 
it's worth.

I think the idea of forking off certain releases in the 2.6.x.0 form, to only 
recieve bugfixes and security updates, is a very good idea. A couple of 
points against it were raised above, but I think if it were approached the 
right way, they wouldn't be issues.

There wouldn't be a huge maintenance overhead, as

  -- The forks would only need to happen occasionally. When 2.6.y has advanced 
past 2.6.x (y > x) sufficiently (i.e. it has significant new functionality) 
and it has been released for sufficient time to iron out obvious bugs, then 
if it comes to be considered a particularly stable release, it would be a 
good candidate for freezing at 2.6.y.0. I would think this sort of thing 
would probably only need to happen once or maybe twice per every ten or so 
traditional releases.

  -- The only maintenance that would be needed on these frozen versions would 
be a backport of any critical bugfixes / security issues, when they occur.


The table on the front page at kernel.org could be augmented with an extra 
row, showing the most recent frozen release from the stable tree. Users who 
want a recent _vanilla_ kernel that is unchanging and hopfully highly stable, 
could choose it.

On Sat, 24 Jul 2004 06:57, Timothy Miller wrote:
> Does that mean that 2.6.21 and 2.6.20.1 are two separate forks of
> 2.6.20, one for development, and the other for stability?
>
> How is this fundamentally different from how it was done before with
> odd/even minor numbers?

IMO the process wouldn't mirror the old 2.x / 2.y model because it is much 
more fine-grained. With the old model, changes have to be backported to a 
kernel that is significantly older, and which potentially has seen 
fundamental changes in the releases between (i mean between 2.x -> 2.y). With 
the new model, a release 'freeze' could be made whenever deemed necessary, 
and since it will be a lot closer on the timeline to where the main 
development is happening, backporting the critical stuff should be a lot less 
of a headache.

The important part would be to not go overboard with release freezing, so 
there wouldn't be 10 frozen kernels to backport to. _That_ would be a 
headache.


There's my $0.02. :)

-- 
	Ben