[Xorg] next steps with the xorg tree

[Kendall Bennett]

[Kaleb Keithly wrote]:

> First some minor administrivia:
> 
> 1. Some of you may have noticed the use of the $XdotOrg RCSID tag. 
> Please add one to any files you edit.

Is there really a reason to use these kinds of tags with modern version 
control systems? The reason I ask is that these tags cause a major pain 
when you need to merge the files between differing version control 
systems. Even through the 'official' versions of the source code will be 
in the X.org CVS tree (actually freedesktop.org CVS tree), many 
developers and organisations will be bringing that tree into their own 
private development trees for real work, rather than working direclty 
within the CVS tree itself. When these tags are used, they create 
needless revisions and clutter in the version history for the trees, as 
any new code that gets checked in from the different version control will 
need to be checked back out again once these strings get modified.

Hence I would respectfully request that such tags *not* be used in any 
source code in the X.org tree. Many other projects have stopped using 
these tags for similar reasons.

> 3. Now that XF86 has tagged RC3, I want to have a discussion about
> how we move forward in the xorg tree, post license change. The
> number of files that are polluted with the new license are fairly
> small at this point in time. Most of them have no other changes
> right now except for the license change. 
> 
> The options that come to mind are:
> 
> A. Continue to import the whole XFree86 tree onto the vendor branch as 
> we have done with 4.3.0.1, 4.4RC1, and 4.4RC2.
> 
>    Pro: it's simple.
> 
>    Con: There's a chance that files with the bad license could "leak" 
> into our sources. By this I mean that the CVS vendor branch mechanism 
> could bite us by supplying new files with the bad license from the 
> vendor branch.

When you do a merge with CVS and go to check it in, is there a way to 
diff the files easily to find out what changed (ie: manually catch any 
license changes and ignore those files)? With Perforce I can do a 'diff 
changed files' operation and see diffs for all files that are open from 
the merge operation, which would help to catch this.

Then again if a lot of changed files have the new license (expected as 
things move forward), this would become cumbersome and problematic.

> B. Generate diffs from an XFree86 tree. Prune out diffs for files with 
> the bad license and patch our tree.
> 
>    Pro: ???
> 
>    Con: Have to keep track of which files are polluted so that we never 
> apply patches from them. May have to black-box our own fixes to the 
> files with the bad license.

If you are going to do diffs, you may as well use the CVS tools to do it 
in A above.

> C. Import an XFree86 tree onto the vendor branch after pruning out files 
> with the bad license.
> 
>    Pro: it's nearly as simple as A. No leakage problem. Just have to 
> search for bad licenses, as opposed to B where we have to remember which 
> files have bad licenses.
> 
>    Con: Have to prune the tree before the import.

Once again doing this manually would be more difficult than using the 
tools provided by CVS. If you plan to merge the trees, using CVS and 
diffing stuff within CVS (assuming you can do that) would be far easier 
and less time consuming.

> Any other proposals?

Yeah, fork the tree at the last point before the license change was made 
and not don't bring in any more changed directly from XFree86 ;-)

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~