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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
