[Xorg] X.org CVS branches need to change

Keith Packard keithp at keithp.com
Mon Mar 15 10:17:38 PST 2004


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?

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20040315/b1ac4009/attachment.pgp>


More information about the xorg mailing list