On Tue, 10 Jan 2012 01:02:44 -0800, Jeremy Huddleston <jerem...@apple.com> wrote:
> Another (cleaner) option is to just branch xserver-1.12-branch from > ed8f3c4bd17bddf1369d050ea8e63b9451d887ce (the commit before ajax's > changes landed) and let master chug along towards 1.13. We've not done this in the past, rather we've let people hold on to their patches after the end of the merge window. I do like the notion of merging not-for-1.12 patches somewhere rather than let them live unmerged for months. I can easily do that. Now, the only question is one of names. I'm not sure I like changing where the release is done; keeping it on master makes things straightforward (at least for me, and perhaps for others?). The pending changes could be in a 'next' branch. Each time I merged patches to master I could either: a) merge master->next b) rebase next on top of master a) will result in a ton of merge commits on next, but would keep the temporal ordering of patches 'correct'. b) will make 'next' look a lot cleaner, but lose ordering information. > If these do get reverted rather than doing a branch, ajax, please > squash the two patches I just sent to the list into your tree. I propose to reset master back before the ABI change and then cherry-pick any non-ABI fixes that Adam sent, then re-push master at that point. This will make things pretty, although will cause a mild amount of grief for people tracking the server tree. Then I will take the ABI changes and push them to a 'next' on top of the new master. Please let me know if this seems insane, and what alternatives you'd prefer; sorry for failing to follow our (fairly clear and unambiguous) policy post-RC1... -- keith.pack...@intel.com
pgptbRvXS8ZP6.pgp
Description: PGP signature
_______________________________________________ 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
