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