1.11 release process (was: [PULL] -next branch for 1.11)
daniel at fooishbar.org
Wed Mar 2 03:43:39 PST 2011
On Tue, Mar 01, 2011 at 08:44:20AM -0800, Jeremy Huddleston wrote:
> On Feb 28, 2011, at 22:53, Keith Packard wrote:
> >> 2) I think the early rcs might not have been as well tested because
> >> they relied on xextproto and randrproto versions that were not
> >> released. Perhaps we should ensure that we release rc protos along
> >> with rc servers where appropriate.
> > Do you want to keep X server code from being merged until a suitable
> > proto RC has been released? Or is it sufficient to have code in the
> > proto repo that has been reviewed?
> I think that locked-step changes should be done as simultaneously as possible. We should try not to merge proto updates that cause the server to stop building (as was the case with randr for a while) until both sets are reviewed and can be pushed together. The same goes for tagged releases. I think we should've pushed rc tags of extproto and randrproto to coincide with the server rcs. This would allow someone to build the rc server entirely from tarballs which might allow for more exposure.
Yeah. So, taking the RandR case as an example:
* RandR 184.108.40.206 gets merged to master with an unstable API,
_provided it does not break 1.3 and prior users_;
* RandR 220.127.116.11 could change the API that 18.104.22.168 introduced;
* (and so on, and so forth);
* RandR 22.214.171.1240 gets merged, and at this point would be
API-stable - additions only.
At that point, the only thing that could go wrong would be merging
anything depending on 126.96.36.199 or 188.8.131.52 or whatever into the server,
but just don't do that. Merging code depending on 184.108.40.2060 and beyond
would be fine.
This preserves bisection completely, except when something depends on
x.y.99.z, where z < 900.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the xorg-devel