[GRASS-dev] Upcoming 7.2.0: review which addons to move to core

Sören Gebbert soerengebbert at googlemail.com
Sun Oct 2 12:27:01 PDT 2016


Hi,
In my humble opinion we should accept only new modules in core, that are
covered by gunittets and this should not only be related to addons. Every
new module must have tests.

The consequence in moving addons into core is that the "core" developers
have to maintain those modules. If modifications are performed in the core
C- or Python libraries, then all modules have to be tested against these
changes.

2016-10-01 21:25 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath at nina.no>:

> 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”?
>

Code review by developers is a good idea. Suggestion, only modules
positively reviewed by two developers, should be added to core. This will
enhance the code quality of new modules and will give the addon developers
the opportunity to show their skills in developing good code.

IMHO, to keep GRASS maintainable, we have to issue this kind restrictions.
There is already plenty of hard to maintain code in GRASS, we don't need
more of this.

However, there is still the very nice and comfortable way to use
g.extension to install addons.

Best
Sören


> 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) be
> considered as a kind of “wish list” from the community? Probably more
> voices would be needed, as we currently have no “download statistics” or
> similar measures which may tell us something about the popularity or wide
> spread application of a module that would give reason to integrate it into
> core...
>
> Where should such wishes be collected? A wiki page? Knowing of such
> interest might be an incentive for an addon-developer to write a test or to
> improve documentation...
>
>
>
> 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?
>

>
> Or is that already too much formality and if someone wishes to see an
> addon in core that is simply discussed on ML?
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* grass-dev [mailto:grass-dev-bounces at lists.osgeo.org] *On Behalf
> Of *Sören Gebbert
> *Sent:* 30. september 2016 22:29
> *To:* Markus Neteler <neteler at osgeo.org>
> *Cc:* GRASS developers list <grass-dev at lists.osgeo.org>
> *Subject:* Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to
> core
>
>
>
> Hi,
>
> I would strongly suggest to move only those addons into core, that have
> good documentation, maintainable code and python tests that run in the
> gunittest framework.
>
>
>
> Just my 2c
>
> Sören
>
>
>
> 2016-07-03 20:09 GMT+02:00 Markus Neteler <neteler at osgeo.org>:
>
> Hi,
>
> we may consider to move a few (!) mature addons to core.
>
> Thoughts?
>
> Markus
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20161002/5d73a3a7/attachment.html>


More information about the grass-dev mailing list