[Xorg] X.org CVS branches need to change

[Egbert Eich]

Keith Packard writes:
 > 
 > > Additionally, I think that we would be served just fine by a system in 
 > > which a person or group of people can elect to form their own branch if 
 > > they know that they have development work that requires a branch, but 
 > > that everything else should occur on HEAD.
 > 
 > The one caveat here is that when approaching a release, we may elect to
 > branch some development that would normally go right to HEAD to avoid
 > branching for the relase early in the process.  Again, the precise timing
 > of the branch is tricky, and should be guided by what will probably be less
 > work overall.

I'm a little bit confused as I thought the plan was to have ongoing
development in HEAD while cutting a branch for a release. Timing is
an issue as we need to make clear to people that this branch effectively
means a feature freeze as new features only go into head (after they
have been tested on their branches).
Having the release in a branch would allow one to tag the version that
is finally released and provide bug fixes.
 > 
 > If people are happy with the new plan, we need to figure out how to get 
 > from where we are to where we want to be, and who is going to do the work.
 > I'm no CVS master, so if someone else wants to volunteer, that would be 
 > fine by me.

I am already overloaded with tasks. I think you would do the job just
fine.

 > 
 > We've got lots of tags in the tree:
 > 
 > 	IPv6-REVIEW-BASE
 >         XORG-RELEASE-1-TM-BASE
 >         XORG-RELEASE-1-TM
 >         IPv6-REVIEW
 >         XORG-RELEASE-1-BASE
 >         XORG-RELEASE-1
 >         CYGWIN
 >         XORG-STABLE
 >         XORG-CURRENT
 > 
 > I guess the question is which of these are active and how we can get them 
 > merged back together.

If we know from which branch they have been branched off and if the
last merge point have been tagged properly this is no big deal.

The last merge point needs to be tagged on the version that was
merged in, not on the version the changes where merged into.
Therefore moving the RELEASE-1 branch to head may produce issues
when trying to merge back sub-branches of the release branch.

 > 
 > I don't see any need for a CYGWIN branch at all; branches shouldn't be 
 > permanent obstacles to getting changes onto HEAD, rather they should 
 > provide a staging ground for significant new changes which need a bit of 
 > work before getting applid to HEAD.  Simple fixes for Cygwin/X, and 
 > changes to files used only by Cygwin/X should go right to HEAD.

Only experience can tell how this will work out.

 > 
 > I don't know if any changes have been applied to XORG-CURRENT or 
 > XORG-STABLE yet, if so, we should review them to see if they're suitable 
 > for inclusion in the release or not, and merge those which are onto HEAD.
 > 

Hmmmm, we are loosing sight of our original goal.

Egbert.