* Moritz Lennert <mlenn...@club.worldonline.be> [2016-10-02 13:24:41 +0200]:
On 01/10/16 21:25, Blumentrath, Stefan wrote:
Sounds fair enough as requirements for new core modules. “Maintainable
code” would in praxis mean “the module has undergone a code review by a
core developer”?
Those requirements would add to Markus requirement of “maturity”, which
I would interpret like “the module has been tested in praxis and options
and flags are consolidated” (so no major changes are expected /
planned)...?
I am afraid, it seems only very few of the suggested modules are covered
with unit tests. Most of them have a good documentation. No idea about
the maintainability of the code...
How should we proceed with this topic? Should the named modules (and
from my point of view Moritz OBIA modules would be very welcome too)
They definitely do not meet the enounced criteria, yet. No tests and
AFAIK, most of them have only been used inhouse by my colleagues.
So, I'm happy to have them live addons for now.
This said, I think the requirement of tests is something I would like to
see discussed a bit more. This is a pretty heavy requirement and many
current core modules do not have unit tests...
On the long run, GRASS-GIS modules deserve unit tests. I think we
should invest efforts in this direction.
In this sense, I will try to integrate unit tests for every, hopefully,
useful code I share in form of a module.
Nikos
One thing we could think about is activating the toolbox idea a bit more
and creating a specific OBIA toolbox in addons.
Identified candidates could be added to core once they fulfill the
requirements above. Would that happen only in minor releases or would
that also be possible in point releases?
Adding modules to core is not an API change, so I don't see why they
can't be added at any time. But then again, having a series of new
modules can be sufficient to justify a new minor release ;-)
Or is that already too much formality and if someone wishes to see an
addon in core that is simply discussed on ML?
Generally, I would think that discussion on ML is the best way to handle
this.
Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
