Proposal: 1.8 release and development process changes

[Peter Hutterer]

On Sat, Sep 26, 2009 at 10:50:47AM -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.

Since this is the first time we'd be using this approach, a 2 or 3 month
feature merge window seems fair to those implenting features - it is
probably quite unexpected. For the 1.9 cycle, shortening it would probably
be a good idea.
Once we got used to feature branches, the release schedule should be
reviewed anyway to check if a 6 months cycle is still appropriate. Not
before 1.9 or 1.10 though.

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

The only stage where that would be applicable is the final freeze towards
the end of the cycle. By then, development should have slowed down enough
that the patches still going in are fixes for severe bugs. So it should be
possible simply open a blocker bug for those patches.
By then the onus should also be on the patch submitter, if a patch is quite
needed and no reaction is noticable on the list, a resend and some extra
poking and shouting to wake people up should be in order.

Applying a patch from bugzilla is less convenient than cherry-picking it,
but the general bugzilla interface is superior to the wiki. Per-bug emails,
bug states and a formal method + history of discussion. From a social point
or view we behave better too: in general, we tend to stick explanations why
a bug is accepted or rejected into the bugreports but this isn't necessarily
the case on the wiki. For example, I don't know why
09df7cc5ad7b72d8a23c3e22fc718aad8c16f4d3 was rejected for 1.6.x just by
looking at the wiki page

Cheers,
  Peter

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