Re: Community government, new developers, release cycle

On Thu, Mar 20, 2003 at 01:41:28PM -0800, Eric Anholt wrote: 
> The slow release cycle is a straightforward problem.  Distributions
> (FreeBSD for example) end up shipping the year-old X releases and
> lacking support for significant new hardware.  We have the option of
> backporting drivers, of course, but then that work would be duplicated
> across many distributions, and most of us don't have the time and often
> the hardware and experience necessary to do it.  The solution I think
> would be optimal is running development in two branches, one being HEAD,
> which would be targeted now at XFree86 5.0, and a stable branch, which
> would continue releasing 4.x and backporting tested fixes and updates
> until it's been acceptably replaced by 5.x.  Yes, this would require
> more work by the committers, but that could be alleviated by allowing
> more committers.

XFree doesn't seem that bad in this area - looks like:

 4.1: June 2001
 4.2: January 2002
 4.3: March 2003

So, 7 months, then 14 months. 14 isn't great, but 7 was good.

I would not call release cycles a straightforward problem though. You
have to be very serious about getting several different things right.

Here is what works in my limited experience:

 a) a release team or person empowered to set dates and enforce
    freezes (and that does a good job). this team need not be made up
    of core hackers primarily, but should have some people on it with
    technical clue. It should meet regularly rather than relying on
    mailing lists.

 b) releases strictly time-based (feature freezes kick in at a fixed
    time, regardless of what features are completed; unfinished 
    features get booted).

 c) CVS is always compilable and dogfoodable (working enough so
    developers can all run it themselves).

 d) stable branches must really be locked down. That is, no feature
    backports, only critical fixes. If you don't do this religiously,
    then people get "stuck" on the stable branch and the unstable
    branch gets too "out there" and doesn't get released.

I think you're suggesting not doing d), i.e. 5.0 would have a long 
devel cycle and 4.x would continue to have large feature additions. 

The Linux kernel works this way as well - 2.4.x has heavy backports
while the unstable branch has very long release cycles.

To me things flow better if developers are working on code that
vendors are shipping and users are using, to the greatest possible
extent. And vendors/users should be tracking and contributing to the
code that's actively developed, via patches and bug reports. This
maximizes feedback loops and "synergies" and keeps the machine rolling
forward. If you break the connection between what's actively
used/shipped and what's actively developed, things start to suck and
points a/b/c get harder to sustain.

It's tricky of course, and there's more than one way to do it no
doubt. Others probably have different experiences.

Havoc