Saul Farber wrote: > 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. I am actually hoping this reduces code branches ... both for geotools and geoserver. > Suggestion: > > * Have a running branch of geoserver which tracks gt-trunk. *not* > geoserver-trunk, but a different branch, perhaps called > "geoserver-gt-trunk-sync". I am not sure that suggestion (which occurred to me as well) is quite strong enough - we are operating with this right now except the branch of geoserver is called OWS4. > 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. Darn that hurt my brain; will try and talk myself through that after a break. > 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! Interesting; this conflicts with my recent experience - GeoTools is changing right now in order to facilitate GeoServer development (the fact that this development is scattered across GeoServer branches is a different problem).
Jody ------------------------------------------------------------------------- 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
