Re: RFC: Starting a stable kernel series off the 2.6 kernel

[Matthias Andree <matthias.andree@gmx.de>]

On Mon, 05 Dec 2005, Willy Tarreau wrote:

> However, the problem is that you stop maintaining old versions
> and quickly switch to new ones when a new kernel comes up. I know
> it's not easy, and may be terribly more difficult to maintain
> several versions in a development kernel than in a stable kernel.
> But imagine the users' position : they run 2.6.14.3 which finally
> fixes all their problems. Then they get a new problem, but 2.6.15
> comes out. There will not be any other 2.6.14, so they have the
> choice of staying to 2.6.14.3 or jumping to fresh new and barely
> tested 2.6.15.

"Regression" as the threat of updating. That was the starting point :)

I believe the reason to abandon the previous "stable" branchlet was the
assumption that the new kernel had all fixes from the previous "stable"
merged, i. e. every patch between 2.6.14 and 2.6.14.3 would become part
of 2.6.15 (or the underlying problem addressed by a patch were resolved
some other way).

> What I think should be done is to still maintain older 2.6
> (eg: 2, 3 or 4 previous releases) so that people will have
> the time to switch to a new one. And I think that what Adrian
> wants to do would be useful *only* if he proceeds that way.

Perhaps a fixed number of releases doesn't cut it. Perhaps a fixed time
neither. If the changes betweeen two subsequent releases is low, one or
more extra versions come for free, but if lots of changes go in all over
the map, it's going to be a royal pain.

It ultimately boils down to the question: how far^Wfast the upstream
wants to run away^W^Wprogress from its previous release.

> Also, I think differently from Adrian. He wants to backport
> all new drivers and new features, while I think that they are
> the most sensible parts and the one which bring the more
> changes to the kernel. In fact, we should *only* maintain
> security and critical fixes on older releases. People in the
> need of a new driver must upgrade for this. This is the

I think there is no such thing as The Single One New Driver[tm]. Some
are quite intrusive, some aren't. Sometimes the new driver works with
older kernels (if the driver is self-contained, for instance just a
dozen new lines of code in an existing driver), sometimes not (because
midlayer or core changes are required to support the new driver).

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/