Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 10 Nov 2003 08:58:18 -0200 (BRST) | From | Marcelo Tosatti <> | Subject | Re: Some thoughts about stable kernel development |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |