On Monday 26 November 2001 16:08, Alan Cox wrote:
> > I submit that if the stable tree hasn't calmed down after three or four
> > months, opening a development branch may in fact HELP the situation, and
> > stabilize things faster. You need to vent the patch pressure.
>
> I'd tend to agree there. The new VM would have gone into 2.5.x and then
> back into 2.4
>
> In terms of release cycles there is a better method, that is simply to
> codify what already happens. In truth we have yearly major releases
I also can't think of a distribution that doesn't have at least a yearly
major release cycle.
I suspect part of the reason for the long gap between stabilizations is that
Linus hates maintenance. Of course it's like visiting the dentist: the
longer it takes the bigger a deal it is...
> We went
>
> 1.2
> 1.3.59
> 2.0
> 2.0.30
> 2.2
> 2.2.14-18 merge cycle
> 2.4
>
> What we possibly should do is admit the backport phases (2.0.30/2.2.14/...)
> do in fact occur and go
>
> 2.5
> 2.5 seems kind of solid at some random point but not finished
> 2.6 (2.4 + 2.5 and useful bit driver backport)
> 2.7 (continued 2.5)
> 2.8 (actual release containing the grand changes 2.5 started)
This gets back to the idea of "minor" development cycles (for example 2.5
already HAS enough pending patches for an entire development cycle) that take
6 months because we know what's going to go into them in the first month or
two, vs "major" anything-goes phases (3.0, which 2.2 probably should have
been...) that are a lot more experimental. Right now, everything's a major
cycle. Even though Linus has expressed a desire to do minor ones, it hasn't
happened yet.
The thing is, with a 6 month development cycle that people BELIEVE will only
take 6 months, it's ok to say "hold off until the next time". But asking
people to "hold it" for two years (even if they only THINK it will be two
years) doesn't work, they keep pushing to get it in and the patch pressure
stays high. So it's a stable 2 state feedback loop: if you can do it you can
do it, and if you can't you can't.
The "backport release" idea seems like a nice way to do the "short" cycle
ones. And the interesting thing about that is Linus doesn't have to be
directly involved in these intermediate stabilizations: there could be
another maintainer he could just give his blessing to. All they need is a
bit of holy penguin pee to make the number official, and the attention of
developers (like all those in Red Hat's employ) willing to spend their time
stabilizing rather than beating fresh trails into the jungle...
A backport release really isn't THAT much different than large changes from
your tree being merged into Linus's tree. Just a question of sequencing
(determining what depends on what), isolating, and porting...
Just a thought...
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:24 EST