On Tue, 11 Jan 2000, Horst von Brand wrote:
> Date: Tue, 11 Jan 2000 12:21:28 -0300
> From: Horst von Brand <vonbrand@pincoya.inf.utfsm.cl>
> To: Marco Colombo <marco@esi.it>
> Cc: "Mike A. Harris" <mharris@meteng.on.ca>, linux-kernel@vger.rutgers.edu
> Subject: Re: Standard Development Integration
>
> Marco Colombo <marco@esi.it> said:
>
> [...]
>
> > There are only 2 kernels now. 2.2.xx and 2.3.xx. 2.0.xx is somewhat
> > supported for bug fixes only, and there not much work on it, i think.
> > When 2.4 is released, active support for 2.2.xx will be dropped anyway.
> > So there will be only 2 kernels, 2.4.xx and 2.5.xx.
>
> There are at least 3 under active development right now: 2.0.39pre, 2.2.x,
2.0.39pre is not what i call "active development": it's still supported
for bug fixes. I doubt any major kernel features (knfds, RAID 0.90, ext3,
ReiserFS) will be back-ported. I'm an happy user of 2.0.38 box, i like
having that kernel serie updated. But that's not active development,
please. And i think no one wants it. 2.0.xx is rock-stable, and i love
3 lines patches like 2.0.37 to 2.0.38 (or was it 5 lines? B-)).
"Active development" means new features added, if not major kernel core
redesign. I do hope 2.0.xx won't see that!
> 2.3.x. It seems 1.2.13lmp development stopped, but who knows... and then
> there are the variants from the different distributions (mostly on 2.2.x,
> but also 2.0.x)
It's true. That's precisely what i fear. "Variants" are good, if they
are based on 2.3, the current DEVEL serie, like 2.3.xx-ac/aa. I'm not
proposing any single patch to under development piece of code to go in
one big 2.5.xx. Let developers have their own tree.
People developed against 2.2 because 2.3 was not there,
or because in its early patch levels it was so instable. We had about
6 months of lack of a usabel DEVEL kernel serie (around 2.2.0). People
have been forced to develop on 2.2.xx at that time. Later, they needed to
test they code for stability, and 2.3.xx was not ready for that, so
they published their patches agaist 2.2.xx again. Now, their code is
"usable" (even Alan said that) on 2.2 and has major incompatibilities
with 2.3, and prabably won't be in 2.4. This happaned not only with one
"package", but with many of them (ISDN and RAID at the time of 2.0 - 2.2,
Ext/Reiser FS now, not to mention knfsd...). See my point?
I'm just proposing to shorten the devel cycle not by simply reducing
the time between the first releaase of 2.5.0 and the final of 2.6.0,
which may be a bad thing, but just letting it overlap with the previuos
cycle of 2.3 - 2.4. Numbers means nothing in this context, but let's see
an example. Given a devel cycle on 12 months, we have now a stable release
every year, roughly this way:
3 months of wild changes/core rewriting - 3 months of porting the rest
of the kernel to the new API - 3 months making it stable - RELEASE
3 months of fixes - SPAWN of new devel.
I'm just proposing to have two overlapped cycles, about 6 months apart:
just spawn the new devel when you're at the pre-release step. This way
there's always a place to put development code, with no need to way or
to develop against stable releases... and there's also less pressure
on including "new" features on a nearly stable kernel.
Yes, having two cycles means double work. But also developing against
2.2 and then "backporting" to 2.3 is also double work...
> --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:18 EST