On Sep 30, 2009, at 19:43, Peter Hutterer wrote:
Development model: xserver master will be closed to general commits; itwill be owned by the RM, or one of their delegates. Again, DO NOT COMMIT DIRECTLY TO XSERVER MASTER. Everyone should have their ownxserver trees, and/or one per subsystem (I'll have xserver-xkb and an input tree, I guess Peter will have an input tree, there should be anEXA tree, etc, etc).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?
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.
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.
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).
--Jeremy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
