New release process for 1.8 (READ THIS)
daniel at fooishbar.org
Thu Oct 1 08:04:08 PDT 2009
On Thu, Oct 01, 2009 at 01:36:39AM -0700, Jeremy Huddleston wrote:
> On Sep 30, 2009, at 19:43, Peter Hutterer wrote:
>> Question: tree on people.fdo or branch on the main repo?
>> branches on the main repo have the advantage of the commit list which
>> provides some chance for patch review.
> If we go for a separate tree, would someone be kind enough to explain
> how to set that up and best practices for merging changes from master on
> the main repo into our own tree (when to merge, when to rebase)? I got
> the sh*t knocked out of me figuring out git the first time, and I've had
> the pleasure of not having to deal with multiple repos yet. Plus, I've
> heard conflicting suggestions on when to rebase and when to merge. From
> what I see, merge is correct for anything in the wild, but rebase makes
> your patchset cleaner... so should we be rebaseing our trees against
> master or merging?
In general, a separate tree is practically identical to a branch, at
least in terms of how you use it for commits/etc. As for rebasing vs.
merging, you do a rebase when the history information you get from the
merge is not really relevant. Note that this changes your repo, so if
you're doing it on published branches, then you have to make sure the
people using it and/or developing against it know.
> And in general, how will this affect other DDXs like XQuartz? Assuming
> we go for branches rather than separate trees (which I vote for mainly
> because of my own ignorance of the other solution), should I just have a
> "master-apple" branch in the same way I have "-apple" branches for the
> other god-knows-how-many branches I need to maintain at the moment? If
> that's the case, then I suspect nothing much will change on my end except
> to send periodic requests to merge master-apple into master.
Well, if you had ~jeremyhu/xserver-apple as a separate repository, then
you could just have master, xserver-1.7-branch, etc, and the -apple
would be implied.
>>>> When you want to push something to master, either
>>>> send patches to the list, or send a pull request for your tree.
> I'm going to assume that the testing procedure I already use for XQuartz
> (pushing builds to my users) is sufficient for things in hw/xquartz and
> miext/rootless since I doubt anybody else on the main xorg-devel list is
> going to care enough about those leaves.
Yep, that makes a fair amount of sense to me. :)
> As for the rest of the world, I like this very much because it will give
> me a chance to test changes against xquartz and send fixes to the source
> repo before they get merged. This will certainly help with bisection of
> master to find issues (less dead zones).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091001/5c18bf87/attachment.pgp
More information about the xorg-devel