New release process for 1.8 (READ THIS)

[Jeremy Huddleston]

On Sep 30, 2009, at 19:43, Peter Hutterer wrote:

>>> Development model: xserver master will be closed to general  
>>> commits; it
>>> will be owned by the RM, or one of their delegates.  Again, DO NOT
>>> COMMIT DIRECTLY TO XSERVER MASTER.  Everyone should have their own
>>> xserver 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  
>>> an
>>> EXA 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3333 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091001/7c9f8cd7/attachment.bin