[Xorg] next steps with the xorg tree

[Egbert Eich]

Kaleb S. KEITHLEY writes:
 > 
 > 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.
 > 
 > 2. You may also have noticed the CHANGELOG-CURRENT file at the top of 
 > the tree. When you check your changes in, please take a moment and 
 > update this file. At a minimum the comment should include the bug number 
 > in bugzilla. Your check-in comments should also reference the bug 
 > number. When you check in your changes, please update the bug report 
 > with the list of files you edited and the version number.

Yes, it would be a good idea to add change information to this file.

 > 
 > 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.
 > 
 > 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.
 > 
 > 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.
 > 
 > Any other proposals?
 > 

I've tought about these issues, too.

I would propose C and I'm going to write a script that identifies the
files that are affected and groks CVS so that they are ignored.
I'm not sure if I will fully succeed to automate this but if my
plans work out no manual intervention should be required.
I would however manually resync the full tree to the version just prior
to the license change.

Cheers,
	Egbert.