Hi Tom, On Tue, 2006-01-24 at 11:15 -0700, Tom Tromey wrote: > One idea would be to check it in on a pristine branch (like cvs > import, but we probably don't want to use that in this case) and then > merge it over the generics branch and clean it up there. > > I would suggest putting the code in external/, e.g., external/jsr166. > > I think it would make sense to import it and get it on the branch > before hooking it into the build. That way, fixing it up to work in > Classpath won't have to be a solo effort. > > Comments?
Seems like a nice plan. But please put down precisely how/where the "pristine branch" comes from and how you sanitize it to only include the public domain bits from the jsr166 group. Then we sent that description to FSF-legal and to Doug so we have a clear record where the original source comes from. And we should probably also send it to Doug so the jsr166 group knows how their users/downstream depend on their work (it is probably a similar process the backport project goes through http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/). It would also be good to then have a simple way/description of how to get a diff between this pristine branch and what what we will have in external/jsr166 so it is easy to forward any patches upstream again. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list Classpath@gnu.org http://developer.classpath.org/mailman/listinfo/classpath
