1.11 release process (was: [PULL] -next branch for 1.11)

[Adam Jackson]

On Mon, 2011-02-28 at 21:14 -0800, Keith Packard wrote:

> Do we need more formal rules for merging code? The RandR 1.4 server code
> was merged before the protocol and library APIs had seen sufficient
> review, but we don't have a formal process for either of those
> modules. Anyone know how to help with that?

The rule I've sort of had in mind for protocol changes is something
like: the protocol and client library must have official releases before
any xserver release candidate can release that implements them.

This forces protocol changes to happen earlier in the release cycle, but
I think that's desirable, and should make it easier for downstream
consumers to know when a feature is going to merge.  It also means
people can test RCs with only released tarballs.  It may mean we end up
doing late-cycle reverts if we discover that the server code is
unworkable, but, better than than releasing a broken server.  In some
sense the client API is both easier to define and more important to get
right; do that first, then make the server conform to it.

The only extension for which I could forsee that being onerous would be
GLX, but GLX has one foot in the grave anyway.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110301/97fa4e73/attachment.pgp>