[PULL] 1.12 fix queue
keithp at keithp.com
Wed Jan 11 14:54:48 PST 2012
On Tue, 10 Jan 2012 01:02:44 -0800, Jeremy Huddleston <jeremyhu at 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
Please let me know if this seems insane, and what alternatives you'd
prefer; sorry for failing to follow our (fairly clear and unambiguous)
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 827 bytes
Desc: not available
More information about the xorg-devel