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

[Tom Stellard]

On Tue, Jul 02, 2013 at 01:02:06PM -0700, Ian Romanick wrote:
> 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.
>

+1

I think this is great especially for drivers / state trackers that use
LLVM as it will make it easier to sync up with LLVM releases.

-Tom
 
> This would mean that Mesa 9.3 would be mid-November.  That sounds
> pretty good to me.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev