I'm sure everyone's typing madly right now! I also wrote a long one, but have distilled it here.
Pros: GSIP#6 is clearly a good idea. Why is gt-trunk out there if not to be used? Cons: Having many branches of code around makes bugs really hard to close because you have to patch the same damn thing once for each branch. Suggestion: * Have a running branch of geoserver which tracks gt-trunk. *not* geoserver-trunk, but a different branch, perhaps called "geoserver-gt-trunk-sync". coupled with * Constantly svn merge geoserver-trunk into geoserver-gt-trunk-sync, and then make necessary changes to compile against gt-trunk. This way you have an always-up-to-date patch (svn diff > gs-trunk-to-gt-trunk.patch) taking gs-trunk to gt-trunk. The hard part is that geotools often leads geoserver. It's true that geotools risks going in the "wrong" direction, but geotools is often the leader here. More folks tracking ISO/OGC standards in gt than geoserver, for sure! --saul Jody Garnett wrote: > What I would like to do is have GeoServer trunk and uDig trunk track > GeoTools trunk. GeoServer is the more important of these two for the > following reasons: > - the project is driving current development with WCS and OWS4 > - it has a valued safety net in the form of CITE tests that may catch > errors our own test cases do not > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
