Messages in this thread | | | From | Peter Samuelson <> | Date | Mon, 17 Jan 2000 20:39:05 -0600 (CST) | Subject | Re: Standard Development Integration |
| |
[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/
| |