Nice idea Rob - patch any bug fixes on trunk first ... I like it. > My suggestion is therefore that geoserver helps itself by not accepting > changes to branches until a test case has been identfied or implemented > on trunk (even if trunk has fixed the problem we should have regression > tests in place), and applying exactly the same discipline to geotools > and geoserver. > > Can geotools follow the same discipline, or is there a better way of > achieving this? If there is a geotools policy in place that _should_ > meet these needs - how do we make it more visible and enforce it > better? The related GeoTools policy is here: suggestions on "visibility and enforcement" are welcome - http://docs.codehaus.org/display/GEOT/Working+on+a+stable+branch > Or do we feel we are successfully emerging from a bad place > regardless? (modules, api, coverages and fm stuff moving to geotools > trunk seems to cut both ways - it provides a consolidated opportunity to > test more, but also raises legitimate worries about flow-on effects into > robustness). > > > Rob Atkinson >
------------------------------------------------------------------------- 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
