[Xorg] X.org CVS branches need to change
eich at pdx.freedesktop.org
Tue Mar 16 01:44:29 PST 2004
Harold L Hunt II writes:
> Keith Packard wrote:
> 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.
With the branch concept you'd have your own branch. It would depend
on you if you'd be committing CYGWIN DDX specific things to your branch
or to HEAD. The merit of doing this within your own branch is that
you won't be affected by changes others do until you decide you are
ready to. You can merge in HEAD as often as you want - or not if
you want stability for a while.
However the theory behind all this is that ongoing development takes
mostly place in branches while minor fixes go directly into the trunk.
> 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
That's not correct. When the release is done the RELEASE-1 branch will
be merged back to CURRENT. How this is done is still open but it will
We should always have a branch from which we cut the release.
Together with scheduling features for release this will give us
a finer control over things and allow people to continue working
on whatever the CURRENT branch will be without interfereing with
At release time some tinderboxes should be set up to build the
release branch and beta testers schould be directed to this branch.
> 2) If XORG-RELEASE-1 is going to be merged back to XORG-CURRENT, then
> what was the point of branching so soon?
So you give the RELEASE branch more time for testing.
You never get sufficient testing when you constantly bring
in stuff from active development.
> 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.
Right. That's not how we do it.
> 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.
Different projects have different models. We should be similar to
what others do but if we are convinced that doing something different
has advantages we should not be the slaves of the crowd.
> 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.
This depends. I assume that still needs to be hammered out. Only
experience can tell what would be the best balance.
More information about the xorg