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

[Felix Oxley <lkml@oxley.org>]

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
-
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/