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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
