Proposal: 1.8 release and development process changes

[Keith Packard]

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
from.

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 intel.com