[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/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:18 EST