[forum] A strawman proposal for X.org & XFree86.org

[Stuart Anderson]

On Fri, 28 Mar 2003, Kendall Bennett wrote:

> I am not familiar enough with CVS to know whether this would make merges
> easier or not, but I am very familiar with Perforce (what we use).

In general terms Perforce and CVS have the same capabilities.

> easier or not, but I am very familiar with Perforce (what we use). With
> Perforce I regularly maintain an entire //depot/cvs/ tree in our server,
> that contains verbatim source code from external projects such as
> XFree86, wxWindows, Mesa and other projects that we track. Some of it
> comes from CVS, and some comes from tarballs. We reguarly import external
> code updates into that tree, tag them and submit them into the branch.

Right, but for the most part, the bulk of the code is all flowing in one
direction: Original code->Vendor/Verbatim branch->Development branch. There
is usually a small amount of code that flows in the opposite direction as
fixes and patches.

> Anyway the point I am trying to make is that keeping a complete, local
> copy of the SSI source code in the XFree86 CVS tree may make a lot of
> sense from the perspective of simplifying the process of merging code
> between the SSI tree and the XFree86 tree. Especially if the X.org
> members are willing to actively maintain and test the SSI tree in the
> XFree86 CVS system.

Keeping the SSI code in the XFree86 repository is an improvement over the
seperate repositories which exist today. The amount of effort spent on the
SSI (often times 2 full-time people) however, should instead be applied to
a single combined tree.

> Of course all this assumes that it makes real sense to have a separate
> SSI and XFree86 tree (I don't understand the issues enough to comment
> here).

Bingo! Maintaining two active branches is not a very efficient way to be
doing things. It causes wasted effort by having to continue merging
patches between the two branches. This effort could be better spent fixing
a single branch. It also causes half of the testing to be not applicable,
another waste of resources.


                                Stuart

Stuart R. Anderson                               anderson@netsweng.com
Network & Software Engineering                   http://www.netsweng.com/
1024D/37A79149:                                  0791 D3B8 9A4C 2CDC A31F
                                                 BD03 0A62 E534 37A7 9149