[GRASS-dev] too many branches

[Sören Gebbert]

2012/8/22 Martin Landa <landa.martin at gmail.com>:
> 2012/8/22 Hamish <hamish_b at yahoo.com>:
>> 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