In some (robust!) discussion on the Geoserver release process, it has come to light that there are some mismatches, at least perceived, between practices in geotools and geoserver tracking fixes to trunk.
In particular, geoserver has been aggressive about ensuring trunk gets patches "forward ported" where necessary, and at the same time there is some level of distrust with the robustness of this process in geotools. Nevertheless, geoserver trunk has made the big step to track geotools trunk, which should provide significantly better testing opportunities for geotools trunk. There remains various degrees of nervousness about this, and I'm not sure there is a well implemented and understood geotools policy (and practice!) that meets the expectations and requirements the geoserver community is aiming at. Its probably also inevitable that geoserver, having for such a long time being bound to previous geotools releases, has in turn resulted in a focus on fixing geotools branches, without a corresponding motivation to port changes forward. (and I know about the issue because I've been as guilty as anyone - I did lots of fixes to Oracle on the complex-features branch which I did not feel able to propagate through to geotools trunk because there was no geoserver trunk tracking it to perform end-to-end tests, and I couldnt work out how to set up Oracle testing fixtures at the time. Online test profiles to the rescue! ) 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? 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
