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

Felix Oxley
2005-12-12T18:53:34Z

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.
>
>> 2. The submitter would identify through GIT when the error had been
>> introduced
>
> Hard to find out. Nobody will do so.
>
>> so that the the person responsible could be CC'ed, also
>> anybody who had worked on the code recently would be CCed, therefore
>> the programmers who were most familiar with that section of code
>> would be made aware of it.
>
> Cc:ing them is part of the development anyway (in reality, Cc:ing
> anybody
> interested in the area). 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'?)

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

>> 4. The programmers mentioned in (2) would ACK the patch which would
>> then become part of an 'official' fixes list.
>
> Won't happen.
>
>> 5. If a volunteer wanted to maintain, say, 2.6.14 + fixes, they could
>> build and test it and be a point of contact regarding any problems.
>> These could hopefully be tracked down and submitted as a new fix
>> patch.
>
> Go right ahead. Just be warned that distributions hired a small
> army of
> kernel specialists to do exactly this, and got tired of doing so.
> Among
> others because the patches deemed necessary were different from one
> distributuion to the next, and then usually incompatible with one
> another
> and with what turned out to be the standard solution. This gave
> rise to the
> current development model...
>
> Armchair software engineering is much like armchair $SPORT.

I am guilty :-)

Thanks for your reply.

regards,
Felix