Proposal: 1.8 release and development process changes

Keith Packard keithp at
Sat Sep 26 10:50:47 PDT 2009

Excerpts from Peter Hutterer's message of Sat Sep 26 08:08:42 -0700 2009:

> 1. Feature branches:
> 2. Three stages: feature merge - bugfix - release freeze
>    I think 3 + 2 + 1 months should be approporiate for the various stages.
> 3. Predictable time-based releases

I like this proposal, one question I have is whether 3 + 2 + 1 is the
right ratio. The kernel does it backwards, with feature merging
happening in a fairly short time followed by the first RC, then a
lengthy amount of testing/fixing before the final release. But, the
kernel also runs a much faster clock and so missing a feature merge
window doesn't cause as much delay before release.

One potential change I might suggest is the wiki-based bug-application
method that we've been using for the 1.6 releases. I've really found
that a great way to avoid losing patches. And, frankly, cherry-pick is
a whole lot easier to work with than applying patches from email. The
only question is where such patches should be stashed while waiting to
be applied, as we wouldn't nominally have a valid 'master' to pull

So, I think we should give this a try for 1.8 and see how it goes; it
seems mostly like a formalization of the current process.
keith.packard at

More information about the xorg-devel mailing list