Messages in this thread | | | Date | Tue, 18 Jan 2000 18:34:34 +0100 (MET) | From | Marco Colombo <> | Subject | Re: Standard Development Integration |
| |
[NOTE: i had to paste this by hand... all the last part of your message should be there anyway.]
[me] > > 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.
[Peter Samuelson] > 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
Good reason. The only thing i have to object to it is that there are so many developers now (and many of them organized as indipendent teams) that only a small number of them fit the 'Gee! There's a new kernel to play with!' model. And there are more companies commercially supporting Linux today than there were a couple of year ago (at 2.0 time). THEY won't stop supporting a certain feature only bacause there's a new kernel to play with, i think...
> 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
It's that 'making it somewhat more inconvenient to develop new stuff' that I'm pointing out! I agree it was better to do that at 2.0 times, but I'm wondering if that makes us pay today more that it gives!
> 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
I happended to agree years ago. I'm not sure now. Maintaining a big project knowing that it touches some kernel internals as a separate branch against a stable kernel, without a main devel branch to refer to (for months) can be expensive, in terms of finding yourself releasing on the old kernel instead of the new one, or having to do a lot of work to port to the new kernel (or both). I'd like to hear from the ReiserFS team if they think that's what happened to them (it's what i suspect, but i really don't know and can't tell...).
> 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.
I don't know much of Debian, so I can't comment on this. I just say that you can have a long freeze-to-release time and at the same time a short release-to-release time, which is what really matters. I don't know if that's what Debian people have (or aim to have). Having more than two active branch (say three: one STABLE, one DEVEL-TO-STABLE, one WILD-DEVEL) can give you LONG freeze-to-release and yet short release-to-release time. I don't think it fits the Linux kernel development process, since the former relays on changes being "regular" in time and size. In kernel land, even a small change in the (kernel to kernel) API may break a lot, while a complete rewriting that maintains the API intact can be carried on with no impact on other kernel parts (this is important because there are usually many-to-one relationships, just like the FSes to VM one). So you can't really plan kernel changes in advace. We can't plan 2.7 changes now... I think we need just two branches. Anytime. Right now the devel one disappears for months.
> > Peter >
Thank you for pointing out what exacly the problem is. It's all in the 'making it somewhat more inconvenient to develop new stuff'. I think we should change it, to allow easier serious development at any time.
Of course I know that's Linus' choice. I'm just making out arguments, not asking him to do that tomorrow...
.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/
| |