[Xorg] X.org CVS branches need to change
Harold L Hunt II
huntharo at msu.edu
Mon Mar 15 11:55:23 PST 2004
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
> 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
> 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
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
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.
More information about the xorg