Hi,
we may consider to move a few (!) mature addons to core.
Thoughts?
Markus
Markus Neteler wrote
Hi,
we may consider to move a few (!) mature addons to core.
Thoughts?
Markus
_______________________________________________
grass-dev mailing list
grass-dev@.osgeo
What are the criterias to move to core? usefulness, code matureness,...?
-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Upcoming-7-2-0-review-which-addons-to-move-to-core-tp5274533p5274543.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
Any imagery modules that would be possible candidates?
On 03/07/2016 20:09, Markus Neteler wrote:
Hi,
we may consider to move a few (!) mature addons to core.
Thoughts?
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
-----
Yann Chemin
Address: 3 Toul Melin, 56400 Plumergat
Mobile: +33 (0)7 83 85 52 34
On Jul 4, 2016 12:26 AM, “Yann” <yann.chemin@gmail.com> wrote:
Any imagery modules that would be possible candidates?
Why not… which do you have in mind?
The general criteria are
- code follows submission standards
- must be portable
- must be well documented with examples
- must be of interest to a wider audience
- …
Markus
On Sun, Jul 3, 2016 at 6:32 PM, Markus Neteler <neteler@osgeo.org> wrote:
The general criteria are
- code follows submission standards
- must be portable
- must be well documented with examples
- must be of interest to a wider audience
I would add "well tested (i.e. very mature) or having somebody willing to
fix it (soon) if needed".
Related to that, I wonder if we should create some standard mechanism for
introducing experimental things - things which might later show as
unstable, not useful or buggy. For example, I introduced v.decimate which
is now in 7.2 branch. It has its merit but I started to think that perhaps
a different set of functions or interface can be more useful there. I
wonder if I should just put [experimental - use with care] at the end of
the module description.
This is out-of-topic here, but similarly we might want to introduce
something like [deprecated] for modules, options and flags.
Vaclav
Vaclav Petras <wenzeslaus@gmail.com> writes:
On Sun, Jul 3, 2016 at 6:32 PM, Markus Neteler <neteler@osgeo.org> wrote:
The general criteria are
- code follows submission standards
- must be portable
- must be well documented with examples
- must be of interest to a wider audienceI would add "well tested (i.e. very mature) or having somebody willing to fix it (soon) if needed".
Related to that, I wonder if we should create some standard mechanism for introducing experimental things - things which might later show as unstable,
not useful or buggy. For example, I introduced v.decimate which is now in 7.2 branch. It has its merit but I started to think that perhaps a different set of
functions or interface can be more useful there. I wonder if I should just put [experimental - use with care] at the end of the module description.
I would add the following:
1) add [experimental] / [beta] / ... behind the in the menu
2) disable the experimental / beta / ... addons
3) add an option to enable all the experimental / beta / ... addons, which can than state
"experimental, might make your computer explode, use at own risk and only in
well ventilated rooms"...
Cheers,
Rainer
This is out-of-topic here, but similarly we might want to introduce something like [deprecated] for modules, options and flags.
Vaclav
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
On Mon, Jul 4, 2016 at 11:00 AM, Rainer M Krug <Rainer@krugs.de> wrote:
Vaclav Petras <wenzeslaus@gmail.com> writes:
This is out-of-topic here, but similarly we might want to introduce something like [deprecated] for modules, options and flags.
...
Related to that, I wonder if we should create some standard mechanism for introducing experimental things - things which might later show as unstable,
not useful or buggy. For example, I introduced v.decimate which is now in 7.2 branch. It has its merit but I started to think that perhaps a different set of
functions or interface can be more useful there. I wonder if I should just put [experimental - use with care] at the end of the module description.I would add the following:
1) add [experimental] / [beta] / ... behind the in the menu
2) disable the experimental / beta / ... addons
3) add an option to enable all the experimental / beta / ... addons, which can than state
"experimental, might make your computer explode, use at own risk and only in
well ventilated rooms"...Cheers,
Rainer
Please open a dedicated ticket for this.
Markus
Markus Neteler <neteler@osgeo.org> writes:
On Mon, Jul 4, 2016 at 11:00 AM, Rainer M Krug <Rainer@krugs.de> wrote:
Vaclav Petras <wenzeslaus@gmail.com> writes:
This is out-of-topic here, but similarly we might want to introduce
something like [deprecated] for modules, options and flags....
Related to that, I wonder if we should create some standard
mechanism for introducing experimental things - things which might
later show as unstable,
not useful or buggy. For example, I introduced v.decimate which is
now in 7.2 branch. It has its merit but I started to think that
perhaps a different set of
functions or interface can be more useful there. I wonder if I
should just put [experimental - use with care] at the end of the
module description.I would add the following:
1) add [experimental] / [beta] / ... behind the in the menu
2) disable the experimental / beta / ... addons
3) add an option to enable all the experimental / beta / ... addons, which can than state
"experimental, might make your computer explode, use at own risk and only in
well ventilated rooms"...Cheers,
Rainer
Please open a dedicated ticket for this.
Done:
https://trac.osgeo.org/grass/ticket/3092
Rainer
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
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@osgeo.org>:
Hi,
we may consider to move a few (!) mature addons to core.
Thoughts?
Markus
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
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) 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
···
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@osgeo.org>:
Hi,
we may consider to move a few (!) mature addons to core.
Thoughts?
Markus
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
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...
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
* Moritz Lennert <mlennert@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 releaseOr 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
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@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@lists.osgeo.org] On Behalf Of Sören Gebbert
Sent: 30. september 2016 22:29
To: Markus Neteler <neteler@osgeo.org>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to coreHi,
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@osgeo.org>:
Hi,
we may consider to move a few (!) mature addons to core.
Thoughts?
Markus
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
2016-10-02 13:24 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
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…
You are very welcome to write the missing tests for core modules.
However, i don’t understand the argument that because many core modules have no tests, therefore new modules don’t need them. If developers of addon module are serious about the attempt to make their modules usable and maintainable for others, then they have to implement tests. Its and integral part of the development process and GRASS has a beautiful test environment hat makes writing tests easy. Tests and documentation are part of coding and not something special. I don’t think this is a hard requirement.
There is a nice statement that is not far from the truth: Untested code is broken code.
Best
Sören
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
On Sun, Oct 2, 2016 at 9:43 PM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
2016-10-02 13:24 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
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...You are very welcome to write the missing tests for core modules.
However, i don't understand the argument that because many core modules have
no tests, therefore new modules don't need them. If developers of addon
module are serious about the attempt to make their modules usable and
maintainable for others, then they have to implement tests. Its and integral
part of the development process and GRASS has a beautiful test environment
hat makes writing tests easy. Tests and documentation are part of coding and
not something special. I don't think this is a hard requirement.There is a nice statement that is not far from the truth: Untested code is
broken code.
these gunittests only test if a module output stays the same. This
does not mean that a module output is correct. Tested code means first
of all that the code has been tested with all sorts of input data and
combinations of input data and flags. All these tests, e.g. what I did
for i.segment or r.stream.* (where I am not even the main author)
should IMHO not go into a gunittest framework because then running
gunittests will take a very long time. In short, simply adding
gunittests to addon modules is not enough, code needs to be tested
more thoroughly during development than what can be done with
gunittests.
My guess for the r.stream.* modules is at least 40 man hours of
testing to make sure they work correctly. That includes evaluation of
float usage, handling of NULL data, comparison of results with and
without the -m flag. Testing should be done with both high-res (LIDAR)
and low-res (e.g. SRTM) DEMs.
my2c
Markus M
Best
SörenOne 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 releaseOr 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_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
2016-10-02 21:27 GMT+02:00 Sören Gebbert <soerengebbert@googlemail.com>:
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.
we should have definitely some official procedure (requirements) for
"graduating" module being part of core. Ideally written as a new RFC.
Does it make sense to you, any volunteer to start working on a draft
of RFC #6?
Martin
[1] https://trac.osgeo.org/grass/wiki/RFC
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
Hi Markus,
2016-10-04 16:13 GMT+02:00 Markus Metz <markus.metz.giswork@gmail.com>:
My guess for the r.stream.* modules is at least 40 man hours of
testing to make sure they work correctly. That includes evaluation of
float usage, handling of NULL data, comparison of results with and
without the -m flag. Testing should be done with both high-res (LIDAR)
and low-res (e.g. SRTM) DEMs.
about r.stream modules, ASAIR the major blocker for these modules to
be moved to core is problem is memory mode, right? I don't remember if
there is any ticket about that. Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
Martin Landa wrote
Hi Markus,
2016-10-04 16:13 GMT+02:00 Markus Metz <
markus.metz.giswork@
>:
My guess for the r.stream.* modules is at least 40 man hours of
testing to make sure they work correctly. That includes evaluation of
float usage, handling of NULL data, comparison of results with and
without the -m flag. Testing should be done with both high-res (LIDAR)
and low-res (e.g. SRTM) DEMs.about r.stream modules, ASAIR the major blocker for these modules to
be moved to core is problem is memory mode, right? I don't remember if
there is any ticket about that. Martin
at least as a comment in this ticket:
https://trac.osgeo.org/grass/ticket/2237#comment:1
-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Upcoming-7-2-0-review-which-addons-to-move-to-core-tp5274533p5289237.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
Hi,
···
You are very welcome to write the missing tests for core modules.
However, i don’t understand the argument that because many core modules have
no tests, therefore new modules don’t need them. If developers of addon
module are serious about the attempt to make their modules usable and
maintainable for others, then they have to implement tests. Its and integral
part of the development process and GRASS has a beautiful test environment
hat makes writing tests easy. Tests and documentation are part of coding and
not something special. I don’t think this is a hard requirement.There is a nice statement that is not far from the truth: Untested code is
broken code.these gunittests only test if a module output stays the same. This
This is simply wrong, please read the gunittest documentation.
does not mean that a module output is correct. Tested code means first
of all that the code has been tested with all sorts of input data and
combinations of input data and flags. All these tests, e.g. what I did
The gunittest framework is designed to do exactly that.
It has plenty of methods to validate the output
of modules, ranging from key/value validation, over statistical analysis of the output, to md5
checksum validation for raster, 3D raster, vector and binary/text file output.
It can test floating point output to a specific precision to avoid rounding errors or to consider the
variability of a random number based algorithm like random forest or boosted regression trees.
for i.segment or r.stream.* (where I am not even the main author)
should IMHO not go into a gunittest framework because then running
gunittests will take a very long time. In short, simply adding
gunittests to addon modules is not enough, code needs to be tested
more thoroughly during development than what can be done with
gunittests.
The gunittest for the v.stream.order addon is an example how its done:
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py
You can write gunittests that will test every flag, every option, their combination and any output of a module. I have implemented plenty of tests, that check for correct error handling. Writing tests is effort, but you have to do it anyway. Why not implementing a gunittest for every feature while developing the module?
My guess for the r.stream.* modules is at least 40 man hours of
testing to make sure they work correctly. That includes evaluation of
float usage, handling of NULL data, comparison of results with and
without the -m flag. Testing should be done with both high-res (LIDAR)
and low-res (e.g. SRTM) DEMs.
Tests can be performed on artificial data that tests all aspects of the algorithm. Tests that show the correctness of the algorithm for specific small cases should be preferred. However, large data should not be an obstacle to write a test.
Best regards
Soeren
my2c
Markus M
Best
SörenOne 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 releaseOr 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
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Tue, Oct 4, 2016 at 5:42 PM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
Hi,
>
> You are very welcome to write the missing tests for core modules.
>
> However, i don't understand the argument that because many core modules
> have
> no tests, therefore new modules don't need them. If developers of addon
> module are serious about the attempt to make their modules usable and
> maintainable for others, then they have to implement tests. Its and
> integral
> part of the development process and GRASS has a beautiful test
> environment
> hat makes writing tests easy. Tests and documentation are part of coding
> and
> not something special. I don't think this is a hard requirement.
>
> There is a nice statement that is not far from the truth: Untested code
> is
> broken code.these gunittests only test if a module output stays the same. This
This is simply wrong, please read the gunittest documentation.
but then why does
The gunittest for the v.stream.order addon is an example how its done:
https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.stream.order/testsuite/test_stream_order.py
assume certain order numbers for features 4 and 7? What if these order
numbers are wrong?
Recently I fixed bugs in r.stream.order, related to stream length
calculations which are in turn used to determine stream orders. The
gunittest did not pick up 1) the bugs, 2) the bug fixes.
You can write gunittests that will test every flag, every option, their
combination and any output of a module. I have implemented plenty of tests,
that check for correct error handling. Writing tests is effort, but you have
to do it anyway. Why not implementing a gunittest for every feature while
developing the module?My guess for the r.stream.* modules is at least 40 man hours of
testing to make sure they work correctly. That includes evaluation of
float usage, handling of NULL data, comparison of results with and
without the -m flag. Testing should be done with both high-res (LIDAR)
and low-res (e.g. SRTM) DEMs.Tests can be performed on artificial data that tests all aspects of the
algorithm. Tests that show the correctness of the algorithm for specific
small cases should be preferred. However, large data should not be an
obstacle to write a test.
I agree, for tests during development, not for gunittests.
From the examples I read, gunittests expect a specific output. If the
expected output (obtained with an assumed correct version of the
module) is wrong, the gunittest is bogus. gunittests are ok to make
sure the output does not change, but not ok to make sure the output is
correct. Two random examples are r.stream.order and r.univar.
Markus M
Best regards
Soerenmy2c
Markus M
>
> Best
> Sören
>
>>
>> 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
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev