Re: Standard Development Integration

From: Peter Samuelson (peter@cadcamlab.org)
Date: Mon Jan 17 2000 - 21:39:05 EST


  [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.

> 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.

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.

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.

> > 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.

> 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.

A lot of projects do this. Debian, for example, just froze 2.2
("potato") development this weekend, and Richard (the release manager)
simultaneously opened the 2.3 ("woody") branch. Samba currently has
three CVS branches, too. (And HEAD, the 3.0.0pre branch, isn't even
officially "frozen", last I heard.)

Do you know the real reason Linus doesn't do this? I don't think it's
the added burden of supporting two branches for a longer period of
time. The real reason (at least one of the reasons) is psychological:
to encourage developers to work on making 2.2.0pre and 2.2.x stable
before spending all their time and energy adding new hairy features to
2.3. By not *having* a 2.3 until 2.2 had settled down to a fairly
stable state, Linus was purposely making it somewhat more inconvenient
to develop new stuff, because you would *have* to maintain it as a
separate patch. You could still do it, and people did (Hans continued
to work on reiserfs, Richard kept polishing devfs patches, etc), but
the *incentive* was to fix bugs in 2.2 instead.

I happen to agree with Linus. As much as I like Debian, I think having
an "unstable" branch to coexist with "frozen" is counterproductive, and
is probably one reason Debian has the (well-earned) reputation for
their l-o-n-g freeze-to-release time.

Peter

-
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:17 EST