Proposal: 1.8 release and development process changes

[Dave Airlie]

On Sat, 2009-09-26 at 10:50 -0700, Keith Packard wrote:
> 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.

I had a different idea, we have this thing call git, why don't we use
it.

make a 1.6-nominate branch, let everyone cherrypick onto it, the 1.6
maintainers reviews this branch, picks what they want off it and
*reverts* with explanations the ones they don't. Or just reverts the
ones they don't want and pulls into 1.6. This way you get to keep
proper history where it belongs in the git tree. If you have to use a
wiki we've already lost.

Dave.