[Mesa-dev] [RFC] Mesa 9.2 and release process changes

[Ian Romanick]

To keep our six-month release cadence, it looks like we'll target August 
22nd for 9.2.  That means we'll probably need to make the release branch 
on July 18th... that's just over two weeks from now.

Assuming that works for everyone, I'd like to propose a couple changes 
to our post-9.2 release process.

1. Carl Worth is taking over stable releases from me, so I'd like to 
increase the rate of stable releases from (nominally) monthly to every 
two weeks.

2. Instead of just posting md5sum for the release tarballs, I think we 
should start GPG signing them.  I'm not sure what sort of process we 
want to establish for this.  Should they just be signed by the release 
managers key?  Is this easier than I think it is?

3. I'd like to make some adjustments to our process for picking patches 
back to the stable branch.  The current process is okay, but it has some 
kinks.  The two big (related) problems are people either under-mark 
things for the stable branch or over-mark.  We also have the problem 
that things are occasionally marked for stable that, in the end, 
shouldn't go to stable.

Instead of the current system, I'd like to propose creating a 
mesa-stable mailing list where candidate patches will be sent.  The 
release manage will then have the responsibility to apply patches to the 
branch.  This gives opportunity for subsystem maintainers to ACK or NAK 
patches before they land.  It also gives the opportunity to use a build 
bot to pre-verify that no patch ever breaks the build on the stable branch.

Anyone can nominate a patch for stable by sending it to the list.  This 
provides a means for solving the under-mark problem.  It may mean that 
developers have to do more work (e.g., waiting awhile after a patch 
lands on master to send it to the stable list), so we may need to come 
up with some means to mitigate that.

As part of this, we need to clearly document the criteria for inclusion 
in the stable branch.  We have some vague criteria now, but we should 
formalize and agree on the list.

4. With the above changes in the stable releases, I'd like to increase 
the rate of major releases from six months to three months.  A lot of 
good work (new features, performance improvements, etc.) sit on master 
for a really long time before getting into a release.  As a result, many 
distros ship some semi-random point from master.  Given that we allow 
regressions to pile up on master (to be fixed during the stabilization 
period), this is a pretty terrible situation.

This would mean that Mesa 9.3 would be mid-November.  That sounds pretty 
good to me.