2012/8/22 Martin Landa <[email protected]>: > 2012/8/22 Hamish <[email protected]>: >> er, we _are_ focusing our energy on GRASS 7 development... ? > > just check new features implemented in grass7 and you will find out > who from developers is focused on grass7. If _we_ would be really be
I have a clear focus on grass7 and do not backport any new features or code reviews i introduce in grass7 to grass6 branches by intention. :) All additional projects that i am developing (wps and vtk bridges, tag2e) are based on grass7. The grass6 test suite that i have implemented is not maintained any more, but available here: http://code.google.com/p/grass6-test-suite/ It can still be used to improve stability and maintainability of grass6 ... but must be updated to use new/renamed options and flags that have been introduced to several modules. IMHO for the sake of maintainability and stability of grass7: we all should implement tests for existing, modified and new modules and libraries. I try this with most of the module and libraries i maintain (gpde, gmath and g3d libraries, 3D raster and temporal modules, Python temporal GIS library) ... but that's not enough. Unfortunately, the module and library test suite we discussed at the code sprint in Prague 2011 is still in a conceptional state ... . But most of the Python code in grass7 outside of modules (lib/python and GUI) can be tested with doctests and unit tests. Please consider Pietro's really nice doctests in the GSoC pygrass project. With pygrass we can directly tests raster and vector library functions, several tests are already available. Just my 2 test cents Best regards Soeren _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
