On 15 Jan 2000, Peter Samuelson wrote:
> Date: 15 Jan 2000 23:22:59 -0600
> From: Peter Samuelson <peter@cadcamlab.org>
> To: Marco Colombo <marco@esi.it>
> Cc: Horst von Brand <vonbrand@pincoya.inf.utfsm.cl>,
> linux-kernel@vger.rutgers.edu
> Subject: Re: Standard Development Integration
>
>
> [Marco Colombo <marco@esi.it>]
> > If they're at 30% of the initial implementing phase when Linus calls
> > a feature-freeze, right now they have no other choice, if they want
> > to go on working. Since it makes a lot of sense for them to keep
> > their patches up to date with kernel patchlevels, in the end they
> > find themselves working on the lastest *stable* kernel, say
> > 2.2.
>
> So far so good.
>
> > Eventually, when they're at 95% of development, and need some
> > extensive testing, they make a public release. A new feature appears
> > for a *stable* kernel.
>
> OK. As long as the new feature is self-contained, it will often be
> included in stable patchlevels (marked EXPERIMENTAL). If it isn't, the
> developer will have to maintain it in parallel until the next devel
> branch is opened up. This is as it should be.
This is as it is now. I think it should be different. If the new feature
is self-contained, by definition it requires minimal work to be ported
to future kernel releases. I think that if the code is stable, it goes
into the stable release, and then it's just a matter of maintain it.
If the project is just an idea, of course it goes into the next devel
release. You're not considering projects which are at 50% when the
stable release is close. Do they have to wait for the next devel release
(months)? Or do they go on developing against the stable release?
Months later, when 'devel' is out, and they're at 90%, what should they do?
(remember, we're in the "not-self-contained" case, here). Drop it
and look at the new devel kernel, hoping that no major changes will force
them to redesign the whole thing from the beginning? Or go on with it,
looking for beta-testers, doing bug-fixes, and bring it to final stage,
and release it as a separate package for the stable kernel?
>
> > Meanwhile, the new main kernel devel branch (2.3) appears. If it does
> > not break their code, they're lucky, and may go on in fixing bugs,
> > and have a stable piece of software on 2.2 and (with little effort)
> > on 2.3 (later on 2.4).
>
> This is where your argument breaks down. Did you check patch 2.3.0?
> The compressed patchfile is even smaller than its own PGP signature.
Of course. That's true for the very first 2.3.
> In other words, the act of opening a new development branch does not
> automatically break things.
It did. 2.3.x broke a lot of things soon, with x small if not 0.
For sure, it changed things that has been tested / fixed during the
early 2.2 life. Useless job, from 2.3 point of view. If you know that
something is going to be re-implemented, why fix it? That's a 2.2 matter.
Let 2.3 begin earlier. It can include any fixes from the 2.2 tree, if
they touch something that 2.2 and 2.3 share. Ignore fixes on things that
are going to change in 2.3. Now it's too late for 2.2 - 2.3. But it's
time to think it for 2.4 - 2.5. Getting the list of what will change on
2.5 is not easy by now. Gettint the list of what will NOT change may
be easier. Have an early 2.5 (right before 2.4pre is there): change it,
let people work on it. Everytime a bug is found on the 2.4pre, apply
the fix on 2.5 too, if you know the thing you're fixing in NOT going to
change. Otherwise just ignore it. If later in the life of 2.5 it turns
out that no changes where made, apply the fix from 2.4. You've got the
best of two worlds.
> Here's what really happens. Status quo:
>
> * developer develops against 2.1.x, then 2.2.0pre
> * Linus releases 2.2.0
> * developer keeps developing against 2.2.x
> * Linus forks 2.3.0
> * developer now has a choice: go with the 2.3.x series, or stay with
> the 2.2.x series, or #ifdef for both
>
> What you are suggesting:
>
> * developer develops against 2.1.x
> * Linus releases 2.2.0pre and 2.3.0
> * developer now has a choice: go with the 2.3.x series, or stay with
> the 2.2.0pre/2.2.x series, or #ifdef for both
>
> What is the difference, really?
You forgot to put the timeline. B-)
In my suggestion the choice is easy. Is my code close to stable (say,
at 90%)? If yes, you join the team who's testing and finalizing the
stable branch; if no, you go on with the new devel tree. For you
really *nothing* changes. You go on developing at the phase you are,
and have no pressure in catching up with the new stable release, or in
slowing down waiting for the devel tree. In statu quo, the choice is easy
only if you're at 90% or 5%. Everything in the middle means you have to
go faster or put pressure on Linus to delay the final release, or choose
between sit down and wait for the new devel (which is months) or go on
working on the stable release, which is the wrong direction (we're still
in the non-modular case).
> > We end up with a feature thats work great on 2.2 and is not there on
> > 2.3. This too raises the pressure on delaying 2.3/4, short-circuiting
> > to 1) again.
>
> As long as you have two separate branches of maintained codebase, you
> will have this problem. Developers have the choice: try and keep up
> with multiple branches, or not. Your proposal would not change any of
> that.
If you're saying having to parallel branches will be more resource
(Linus' time) consuming, i agree. If you're saying that in what i'm
suggesting nothings changes, i don't.
>
> Peter
>
.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 : Sun Jan 23 2000 - 21:00:15 EST