[Xorg] X.org CVS branches need to change

[Harold L Hunt II]

Keith Packard wrote:

> Ok, I think we've got general agreement that the current branch structure 
> within the X.org repository isn't entirely necessary, and has led to quite 
> a bit of confusion.  Not that it isn't a good scheme, but it just isn't a 
> match for how CVS is used in an active development project, nor how people 
> are used to it being used in other familiar environments (like DRI).
> 
> I know that changing things will confuse everyone for a while, but I think
> it will be better to do it now to avoid confusing even more people in the
> future.
> 
> Ok, so here's what I propose.  The first thing is that "HEAD" should be 
> where common active development occurs; bug fixes, work towards the next 
> release etc.  
> 
> When the release is "frozen", a branch is made for that release and changes
> necessary for the release are applied to the branch, and (probably) applied
> to HEAD as well.  Timing the branch is a tradeoff between stalling ongoing
> development and the work needed to get the release done as many changes
> will need to be applied twice after the branch point.
> 
> For development which changes lots of stuff and which might well break 
> things transiently, people are welcome to create branches of their own.
> I think the DRI rules are good here -- when you're ready to bring things 
> back to HEAD, you first merge HEAD back to your branch, make that work 
> right, then merge your branch back to HEAD.  (I think this is what DRI 
> does, if not, surely someone will correct me).
> 
> Tinderbox will build HEAD; changes that break Tinderbox will be flamed and 
> the committer will need to fix or back out the change, or at least explain 
> themselves.
> 
> Does any of this seem weird or controversial to anyone?

I second this in its entirety.

I don't see the point in having a separate CYGWIN branch were we work on 
things that, you guessed it, only affect our platform.  It only means 
that I then have to do hours of work to get my patches merged into the 
release branch before the release, or into the XORG-CURRENT branch 
before the release branch is created.  It is a lot of work that provides 
us absolutely *no* benefit at all.

In addition, the XORG-CURRENT and XORG-RELEASE-1 branches do not have 
logical functions.  Consider this:

1) A lot of new patches are being committed *only* to XORG-RELEASE-1. 
These patches will be lost of XORG-RELEASE-1 is not merged back to 
XORG-CURRENT.

2) If XORG-RELEASE-1 is going to be merged back to XORG-CURRENT, then 
what was the point of branching so soon?

3) If XORG-RELEASE-1 is not going to be merged back to XORG-CURRENT, 
then we are going to lose a lot of things that have been committed only 
to XORG-RELEASE-1.

I agree with Keith that the current system is overly complex and does 
not mirror what people (e.g. myself) are used to seeing in CVS. 
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.

Harold