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

Felix Oxley
2005-12-14T00:09:16Z

On 13 Dec 2005, at 13:17, Horst von Brand wrote:

> Felix Oxley <lkml@oxley.org> wrote:
>> On 12 Dec 2005, at 17:17, Horst von Brand wrote:
>>> Felix Oxley <lkml@oxley.org> 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).

Thank you for your explanation.
I will retire to lurk quietly in my armchair. :-)

regards,
Felix