On Tue, 11 Jan 2000, Horst von Brand wrote:
> Date: Tue, 11 Jan 2000 13:27:57 -0300
> From: Horst von Brand <vonbrand@pincoya.inf.utfsm.cl>
> To: Marco Colombo <marco@esi.it>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: Standard Development Integration
>
> Marco Colombo <marco@esi.it> said:
>
> [...]
>
> > 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.
>
> Today that is Linus + DaveM + others concentrating on the experimental
> release, plus Alan Cox and a few others working on the stable one.
Well, right now most of the work is on getting 2.3 stable, i hope.
2.3 won't be THE experimental release forever (and shouldn't be right now,
BTW). Read your last sentence again, and it's what i'm really proposing.
Call 2.3 'the stable one' and 2.5 'the experimental release' and you get
what i'm asking for. Probably it can't be done in a day, since 2.3
is not ready today to be called 'the stable release'. But i think that's
the way to go.
> > 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.
>
> OK, give us a copy of Linus and the head hackers, and they take over the
> other branch.
As you wrote, they're already 'on the other branch'. Just ban all non
working features from 2.3, and go for stability only. In a short time
we can have a quite stable 2.4pre (without many wanted but still new
features). At that time start 2.5 and be ready to put all the new code
in it. In six months (remember, numbers here are just placeholders) we can
have a 2.6 (or 3.0 whatever) with the new features. I'm more willing
to wait 6 months for a 2.6+everything and have 2.4 quite soon than to
wait 4 months for 2.4+everything. Of course that's my personal taste.
Still it sounds good to me to stop adding new features to 2.3 now and
add them to a baby named 2.5.
> > Yes, having two cycles means double work. But also developing against
> > 2.2 and then "backporting" to 2.3 is also double work...
>
> It is not double work, the differences are small(ish) today. If wild
> development goes on on two branches, crossporting will be very dificult and
> they will diverge.
"Wild" development will go on on ONE branch only, of course. Getting
2.3 stable enough to call it 2.4 is not exactly "wild development"...
I'm not an expert, but i can see there are some difficulties in porting
from 2.2 to 2.3. I'm not speaking of generic drivers, but of some of the
JFS code (Ext3 and ReiserFS).
> --
> 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