Re: getting on a longer release cycled

[Havoc Pennington <hp redhat com>]

Elijah Newren wrote:
> [1] I've often worked on big changes that couldn't possibly make it in
> by the next release, including during code freezes.  Sure, I can't
> commit it to HEAD when I'm doing so, but I can keep working on it even
> during hard code freeze (in branches, of course), planning it out for
> some later release.  How many years has work on compositing gone on?
> I don't think a 9-12 month (or even 18 or 24) would have helped it
> actually get in before the "next" release, nor that the overall
> quality of it when it finally does get in would be any higher.

There's a good reason for this really; no matter how long you make the 
cycle, if you allow people to commit stuff to HEAD that essentially 
disassembles the engine and leaves parts all over the floor, you have a 
big problem - nobody else on the team can get anything done because they 
can't dogfood HEAD in order to work on their own changes. (cf. 
pre-GNOME-2.0 for an example of when this happened a lot...)

So, there's a reality that HEAD has to always be roughly working since 
lots of people are trying to work with it.

Given that reality, a longer cycle essentially does nothing to make it 
easier to make large changes, because a branch is required due to 
dogfooding, not due to the short cycle.

Re: the overall discussion, a couple points I'd highlight:
 - perhaps the largest penalty for exceeding a 6-month cycle is that 
distribution vendors start maintaining their own substantial forks 
because they can't count on having HEAD in released form.
 - I don't think something like Topaz is even worth considering unless 
the community can figure out how to decide on some of the focus / target
audience questions I've annoyingly raised ;-) if those aren't answered 
you end up doing the "petrified wood rewrite" (cf. 
http://log.ometer.com/2005-04.html) where it cleans up the code but you 
pretty much have the same thing as before. Just a .02

Havoc