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

[Horst von Brand]

Felix Oxley <lkml@xxxxxxxxx> wrote:
> On 12 Dec 2005, at 17:17, Horst von Brand wrote:
> > Felix Oxley <lkml@xxxxxxxxx> wrote:
> >
> > [...]
> >
> >> What if ...
> >>
> >> 1. When people make a patch set, if they have encountered any 'bugs'
> >> they split them out as separate items.

> > No need. Patches are either (a) bug fixes, or (b) infrastructure
> > changes, or (c) additions (mostly drivers). You only need to pick (a)
> > items. Check.

[...]

> >> 3. When the patch is posted to LKML, it is tagged [PATCH][FIX] in the
> >> subject line.
> >>      In the body of the fix would be noted each kernel to which the
> >>      fix applied e.g [FIX 2.6.11][FIX 2.6.12][FIX 2.6.13][FIX 2.6.14]

> > No do. Problem are the (b) and (c) patches above, they change
> > whatever the patch applies to and make it not apply anymore. The effort
> > of finding out if the patch is (a) or (c) class, seeing if it is really
> > needed, and modifying it so it applies to your source base is called
> > "backporting". And it remains hard, thankless work.
> 
> If this was done for 'trivial' patches of type (a):
> 	1. Would that make it simple enough for people to actually do it?
> 	2. Would it be worthwhile? (Are there enough 'trivial fixes'?)

Not all important fixes are "trivial", far from it; so this is rather
suspect in any case. Changes to the underlying source make even "trivial"
patches soon not apply anymore. And there still is the job of finding out
if some patch is or is not necessary...

> I envisaged something like the current Stable series, just for longer
> than a single release cycle.

Go right ahead. If enough people get interested and work on it, it might
turn out useful. I rather doubt it, as the current development model is
exactly geared towards keeping people up to date, not running ancient
kernels and then jumping a few versions ahead. The problem with doing that
is that instead of one problem at a time you see a dozen, and then it is
hard to pin down /when/ it broke (and thus what change is responsible).
Plus the drift from backported patches, where you can't be sure it /seemed/
to work because of some random patch.

Again, this development model was tried /hard/ for some 12 years by the
distributions, and found sorely lacking (and essentially unfixable).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/