Re: Some thoughts about stable kernel development

From: Marcelo Tosatti
Date: Mon Nov 10 2003 - 06:06:38 EST




On 9 Nov 2003, Krzysztof Halasa wrote:

> Hi,
>
> There is no doubt any development model has some problems, and ours
> can't be an exception. I'd like to share with you an idea which
> recently found a way to my mind.
>
> There is a problem that a development cycle (time between stable
> = non-pre/rc versions) is long. Imagine a situation when we are at
> some pre-3 stage, the kernel tree is full of problems which must be
> resolved before the final release, and some serious security-class
> bug has been found. We would be unable to have a secured stable
> version shortly unless the maintainer checks through all changes to
> last stable kernel, identify fixes which are both safe and necessary
> (hopefully there are no necessary unsafe ones at that time), and
> back-out everything else. Such a scenario is real and that way we might
> end up with official kernel being unusable for any Internet-connected
> tasks for weeks.
>
> Here is what I propose:
> As all of you know, the development cycle can be shortened by using
> two separate trees for a stable kernel line.
>
> Say, we're now at 2.4.23-rc1 stage. This "rc" kernel would also be
> known as 2.4.24-pre1. The maintainer would apply "rc"-class fixes to
> both kernels, and other patches (which can't go to "rc" kernel) would
> be applied to 2.4.24-pre1 only.
>
> After 2.4.23-rcX becomes final 2.4.23, the 2.4.24-preX would become
> 2.4.24-rc1 and would be a base for 2.4.25-pre1.

I really dont understand this "be a base for 2.4.25-pre1".

I guess what you mean is you want a separate 2.4.24-pre tree accepting
"-pre" patches while 2.4.23-rc is "in stage" accepting critical bugfixes
only.

That would be useful yes. Maybe Andrew should do it in 2.6 ?


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