Re: Standard Development Integration

From: Marco Colombo (marco@esi.it)
Date: Wed Jan 12 2000 - 06:51:43 EST


On Tue, 11 Jan 2000, Alexander Viro wrote:

> Date: Tue, 11 Jan 2000 15:43:40 -0500 (EST)
> From: Alexander Viro <viro@math.psu.edu>
> To: Horst von Brand <vonbrand@pincoya.inf.utfsm.cl>
> Cc: Marco Colombo <marco@esi.it>, linux-kernel@vger.rutgers.edu
> Subject: Re: Standard Development Integration
>
>
>
> On Tue, 11 Jan 2000, Horst von Brand wrote:
>
> > 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.
>
> Stop here. You are missing the point - correct mapping is
> -CURRENT x.2y+1.latest
> -RELEASE point of divergence between x.2y an x.2y+1
> -STABLE x.2y.latest
> -RC x.2y.early
> -BETA x.2y-pre and x.2y.very_early
>
> It _is_ isomorphic to *BSD version trees, except that here declaring
> x.2y-pre seems to be the only way to say "It IS freeze, DAMNIT!" that
> really sinks in...

The problem (i see) is that -CURRENT disappers for quite a while after
-BETA comes into existance. I'm proposing to have it never disappear, or
at least having it reappear together with -RELEASE. Right now, -CURRENT
spawns after -RC becomes -STABLE. It's quite a while, and some developers
(of new features) have to work on -BETA, -RELEASE, -RC and -STABLE, or just
wait. None of -BETA ... -STABLE is supposed to see new features, IMHO.
Many fixes that are (ev.) applied to -BETA ... -STABLE can be ported to the
parallel -CURRENT easily, so it will be quite stable until it diverges too
much.

Having x.2y+1.early (new -CURRENT) overlap x.2y-pre, or even 2.2y-1.latest
(-BETA), will prevent people from adding new features to -BETA as a side
effect.

What i'm proposing is to have a main -CURRENT branch that at times spawns
a -BETA ... -STABLE branch, but *never* freezes. When Linus calls a feature-
freeze, -CURRENT should go into -BETA state, and a new -CURRENT should
spawn a bit later (few weeks). This means, in Linux versions, to start
2.5 when 2.4pre is out.

.TM.

P.S.
I thought that -RC comes before -RELEASE... not that it's a matter at all...

-- 
      ____/  ____/   /
     /      /       /			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:19 EST