Re: Standard Development Integration

From: Marco Colombo (marco@esi.it)
Date: Tue Jan 18 2000 - 11:58:22 EST


On Mon, 17 Jan 2000, Peter Samuelson wrote:

> [Peter Samuelson]
> > > 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.
>
> [Marco Colombo]
> > 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.
>
> Not always. Individual filesystems are self-contained, but the VFS API
> has changed a *great deal* between 2.2 and 2.4.

So they relay heavily on the VFS, and are not self-contained B-).
A clean separation, by means of a complex API, does not mean they're
self-contained. If the API is small and simple, that's another matter.
Anyway, whenever an API changes, you're in trouble...

> > 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.
>
> *Nod.*
>
> > 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?
>
> Develop against the stable release. This is actually *easier* than
> developing against a rapidly-changing devel 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).
>
> Start pushing for inclusion into the devel release. (I.e. start
> sending Linus patches.) This is actually the ideal case. As I said
> earlier, 2.3.0 was identical to 2.2.8. So if you have been developing
> against 2.2.7, and Linus simultaneously releases 2.2.8 and 2.3.0, it's
> just as easy to port to 2.3.0 as to port to 2.2.8.

Really, 2.3.0 was devel only by name. No real changes went in it.
If you were at 90%, you needed realworld testing. You could not at the
same time change your code to follow early 2.3 changes (by assumption,
they broke your code). You had to choose. (You could do both things,
if you had infinite developer time, of course).

> No matter *when* you start developing, no matter *what* your release
> cycle is compared to Linus's, you run the risk of having a major kernel
> change undermine some of your work. I don't understand what your
> proposal would do that would change that. If you are 50% done with
> your filesystem (i.e. not ready for even devel-branch inclusion) and
> someone does a major VFS overhaul, you have work to do.

Agreed. That's the worst case (for both).
But let's think of how this could happen, in my schema
(ok, if it takes 3 years to you to finish your project, simply you can't
make it anyway, and you can only release it on "old" kernel. So i'm
assuming your project is somewhat near 6-9 months):

major changes happen at 2.2y+1.quite-early. This means at
2.2y-1.right-after-feature-freeze time. If you're at 50%, you can't make
it for 2.2y. 2.2y+1.quite-early breaks your code. You're completely
out of sync. The difference here is only in that:
1) you knew it before - you started your project late in 2.2y-1 life.
You should have delayed it in order to get in sync with 2.2y+1. This means
taking part in the initial discussion of what will change in 2.2y+1.
In my proposal, that's 1-2 months. Right now it can be 6+ months. (Think
you want to start it *now*, 4-6 months or more before the first 2.5).
2) since the time between two releases is half of what it is now,
there are less 'major changes' in every initial devel release. So
it's easier for you to eventually modify your code to fit the changes.
Or, you have half the chance your code will be affected by the 2.2y-1 ->
2.2y+1 move, which, in the long run, is the same.

> A few months where 2.1.late, 2.2.0pre, and 2.2.x are feature-frozen and
> relatively stable actually *decreases* the chance of this happening to
> you.

If your goal is to release on 2.2 when Linus releases 2.4, you're right.

>
> > > 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.
>
> 2.3.7 was the page cache breakage, which wreaked havoc on mm and
> filesystems. Before that we just had wait-queue cleanup, which was
> almost sed-script material.

So? At the time 2.3.7 was out, you had to choose. Change your code
to work on it, or go on testing on 2.2. At 60+%, you could only
go on on 2.2. At 10% it really doesn't matter if you have to redisign it.
What was the state of ReiserFS, RAID 0.90 at 2.3.7 time? (I really don't
know. I'm just wondering if they were too advanced to follow the 2.3
changes...)

[... rest delayed to another message B-)]

.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:18 EST