[GRASS-dev] Planning GRASS GIS 7.0.0RC1

[Markus Neteler]

Hi devs,

the release of 7.0.0RC1 is currently scheduled for next week, 29th of December.

Concerning the parameter name consolidation, I feel that most work on
this ticket has been done (or will not happen any more for 7.0.0):
http://trac.osgeo.org/grass/ticket/2409

The new parser abbreviation and matching algorithm works nicely in my
opinion. Thanks for that especially to Glynn. It quite facilitates the
transition to the cleaned and improved parameter names.

TODOs for RC1:
* Glynn mentioned that he wants to cleanup something else in the
display architecture.
* A few relevant bugs for RC1 are here:
http://trac.osgeo.org/grass/milestone/7.0.0
* other issues?

See also:
* http://trac.osgeo.org/grass/wiki/Grass7Planning

best
Markus

[Markus Neteler]

Hi,

since the 29th is approaching quickly, please consider to check relbr7
for missing backports. I'm unable to judge them myself.

thanks
Markus

[Markus Neteler]

Hi,

due to incomplete backports (or statements that they should not be
done), RC1 is slightly postponed.
I see notable differences here:
- lib/vector/Vlib/ascii.c
- lib/vector/Vlib/build.c
- lib/vector/Vlib/line.c
- lib/vector/Vlib/map.c
- lib/vector/Vlib/read_pg.c
- lib/vector/Vlib/remove_areas.c
- lib/vector/Vlib/snap.c
- lib/vector/Vlib/write_nat.c

# not present in relbr7:
- lib/vector/Vlib/intersect2.c
- lib/vector/Vlib/net_analyze.c
- lib/vector/Vlib/net_build.c

Not sure what's experimental and what's a forgotten bugfix backports?

New, to be further updated:
http://trac.osgeo.org/grass/wiki/Release/7.0.0RC1-News

thanks
Markus

[Martin Landa]

Hi,

Post by Markus Neteler
Not sure what's experimental and what's a forgotten bugfix backports?

I would also add http://trac.osgeo.org/grass/ticket/2522

Martin

[Martin Landa]

Hi,

Post by Markus Neteler
- lib/vector/Vlib/net_analyze.c
- lib/vector/Vlib/net_build.c

I would say, do not backport. It's related to quite new support for
turns in vector networks [1]. I would say new feature in GRASS
7.1/7.2.

Martin

[1] http://grasswiki.osgeo.org/wiki/Turns_in_the_vector_network_analysis

[Markus Neteler]

Post by Markus Neteler
Hi,
due to incomplete backports (or statements that they should not be
done), RC1 is slightly postponed.
- lib/vector/Vlib/ascii.c
- lib/vector/Vlib/build.c
- lib/vector/Vlib/line.c
- lib/vector/Vlib/map.c
- lib/vector/Vlib/read_pg.c
- lib/vector/Vlib/remove_areas.c
- lib/vector/Vlib/snap.c
- lib/vector/Vlib/write_nat.c

... remain unclear to me.

Additionally, I found the deactivated
grass70/vector/v.in.sites/
.... remove or move to Addons?

Furthermore, many vector/ modules show unbackported differences
--> I cannot judge them.

In display/ are also a series of differences but Martin is working on that.

Then: misc/ + ps/ + raster/ + imagery/ + raster3d/ + scripts/ +
temporal/ I have checked. There are only these relevant differences:
- r.distance (Huidae)
- r.proj bugfixes (Markus Metz)
- r.spread (Vaclav)
- new r3 modules by Anna (perhaps yet experimental)

In general/ there are differences in
- g.rename (Huidae)
- manage/lister (Huidae)

Also the wxGUI differences I'll leave to the experts :-)

Just to bring this to your attention.

Markus

[Martin Landa]

Hi,

Post by Markus Neteler
Additionally, I found the deactivated
grass70/vector/v.in.sites/
.... remove or move to Addons?

I removed this module (it was already done in trunk in r62179). To
convert sites to GRASS 7 you need to use GRASS 6.

In this light I would suggest to move v.convert to addons and remove
'old_vector' from element list. Any objections?

Martin

[Markus Neteler]

On Fri, Jan 2, 2015 at 9:40 AM, Martin Landa <***@gmail.com> wrote:
...

Post by Martin Landa
In this light I would suggest to move v.convert to addons and remove
'old_vector' from element list. Any objections?

Makes sense. If users want to upgrade from GRASS 5 directly to GRASS
7, it will be fine to install an Addon.
Those bulk upgrading from GRASS 6 can use this built-in procedure:
http://grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7

So: yes.

my 0.02,
Markus

[Martin Landa]

Hi,

Post by Markus Neteler

Post by Martin Landa
In this light I would suggest to move v.convert to addons and remove
'old_vector' from element list. Any objections?

Makes sense. If users want to upgrade from GRASS 5 directly to GRASS
7, it will be fine to install an Addon.
http://grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7
So: yes.

done in trunk as r63930. If no objection I will do backport to relbr7
in few days (before RC1) and then move v.convert to addons. Martin

[Martin Landa]

Hi,

Post by Markus Neteler
Also the wxGUI differences I'll leave to the experts :-)

I would not backport the new and still experimental features like data
catalog. Generally speaking I would leave wxGUI as it is. After RC1
only bugfixes.

Martin

[Anna Petrášová]

Post by Martin Landa
Hi,

Post by Markus Neteler
Also the wxGUI differences I'll leave to the experts :-)

I would not backport the new and still experimental features like data
catalog. Generally speaking I would leave wxGUI as it is. After RC1
only bugfixes.

Any idea about the difference in gcmd.py in trunk, it's something about
Windows shell escaping? I don't know how to try it out, to understand if we
want it or not.
http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/core/gcmd.py#L163

Anna.

Post by Martin Landa
Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

Post by Markus Neteler
Furthermore, many vector/ modules show unbackported differences
--> I cannot judge them.
In display/ are also a series of differences but Martin is working on that.
Then: misc/ + ps/ + raster/ + imagery/ + raster3d/ + scripts/ +
- r.distance (Huidae)
- r.proj bugfixes (Markus Metz)
- r.spread (Vaclav)
- new r3 modules by Anna (perhaps yet experimental)
In general/ there are differences in
- g.rename (Huidae)
- manage/lister (Huidae)

I put these notes to trac [1], please mark by ~~ when solved.

Thanks, Martin

[1] http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

[Vaclav Petras]

Post by Martin Landa

Post by Markus Neteler
- r.spread (Vaclav)

I put these notes to trac [1], please mark by ~~ when solved.

The wiki page is saying r63777 [1] which I backported 4 days ago in hurry
[2] because I was afraid that RC1 will be actually released, so I was not
reporting it. There is also r60922 which is extending interface by -i flag
which enables a new feature, copying values from seed map into the output
map. I could backport it, it would be actually advantageous for me to have
it in 70, but it is adding a new feature and I'm afraid I'm the only one
who tested that.

[1] http://trac.osgeo.org/grass/changeset/63777
[2] http://trac.osgeo.org/grass/changeset/63820
[3] http://trac.osgeo.org/grass/changeset/60922

Post by Martin Landa
[1] http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

Hi devs,

proposal for new RC1 release date: 14 Jan 2015.
Let's please manage to keep that date if you agree.

http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

Markus

[Martin Landa]

HI,

Post by Markus Neteler
proposal for new RC1 release date: 14 Jan 2015.
Let's please manage to keep that date if you agree.

I agree. Let's focus on this date. Martin

[Martin Landa]

Hi,

Post by Martin Landa

Post by Markus Neteler
proposal for new RC1 release date: 14 Jan 2015.
Let's please manage to keep that date if you agree.

I agree. Let's focus on this date. Martin

time is running, I would like to kindly ask if there is any progress
in open issues? I can do backport if you confirms which are OK.

Thanks, Martin

[Markus Neteler]

Post by Martin Landa
Hi,

Post by Martin Landa

Post by Markus Neteler
proposal for new RC1 release date: 14 Jan 2015.
Let's please manage to keep that date if you agree.

I agree. Let's focus on this date. Martin

time is running, I would like to kindly ask if there is any progress
in open issues? I can do backport if you confirms which are OK.

Huidae answered yesterday to me. I have added them to the trac page with
rev numbers.
For the others no answer yet.

Thanks
Markus

Post by Martin Landa
Thanks, Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa

[Moritz Lennert]

Post by Martin Landa
Hi,

Post by Martin Landa

Post by Markus Neteler
proposal for new RC1 release date: 14 Jan 2015.
Let's please manage to keep that date if you agree.

I agree. Let's focus on this date. Martin

time is running, I would like to kindly ask if there is any progress
in open issues? I can do backport if you confirms which are OK.

Sorry, no progress on my side, but a new issue I stumbled upon
yesterday: https://trac.osgeo.org/grass/ticket/2533.

Can anyone confirm this ?

Moritz

[Markus Neteler]

Hi devs,

I have now also completed the lib/ tree comparison, done the obvious
backports and identified some differences where I cannot say if to
backport or not:

Kindly extracted with revision numbers...:
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

Please check! (strike there what's done)
The 14 Jan 2015 is getting close.

thanks,
Markus

[Markus Neteler]

Hi devs,

http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

...the TODO list got much shorter!

Relevant differences - to be clarified:
* lib/db/dbmi_base/connect.c
* lib/gis/strings.c G_chop() (Markus Metz) r63308
* Change handling of display frame, graphical clip window (Glynn)
(r62026 + r62036)
* lib/python/script/core.py (martinl) r63528
* db.connect substitute variables for database name (-cpd) (martinl) r59671
* r.spread (Vaclav) r63777
* checks for Vect_open_* return value to avoid potential segmentation
fault: r60054 <<-- wasn't the idea to avoid these ugly tests in G7?

Please check those,

Markus

[Vaclav Petras]

Post by Markus Neteler
* r.spread (Vaclav) r63777

I backported this one before the original RC1 release date. I don't know
how it got to wiki, cleaned now. Now I backported also r60922 which is
probably a feature but since it is in trunk for some time and won't be
probably tested better, I just backported it.

Vaclav

[1] http://trac.osgeo.org/grass/changeset/63777
[2] http://trac.osgeo.org/grass/changeset/63820
[3] http://trac.osgeo.org/grass/changeset/60922
[4] http://trac.osgeo.org/grass/changeset/63820
[5] http://lists.osgeo.org/pipermail/grass-dev/2015-January/072736.html

[Markus Metz]

Post by Markus Neteler
Hi devs,
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
...the TODO list got much shorter!

[...]

Post by Markus Neteler
* checks for Vect_open_* return value to avoid potential segmentation
fault: r60054 <<-- wasn't the idea to avoid these ugly tests in G7?

The Vect_open_* return the open level when opening existing maps, not
just success or failure. Some modules, most importantly v.info, try to
open a map first with topology, if that fails, without topology.
Therefore it is up to the modules to decide if the return code is ok
or not.

Markus M

[Markus Neteler]

On Mon, Jan 12, 2015 at 10:02 AM, Markus Metz
...

Post by Markus Metz

Post by Markus Neteler
* checks for Vect_open_* return value to avoid potential segmentation
fault: r60054 <<-- wasn't the idea to avoid these ugly tests in G7?

The Vect_open_* return the open level when opening existing maps, not
just success or failure. Some modules, most importantly v.info, try to
open a map first with topology, if that fails, without topology.
Therefore it is up to the modules to decide if the return code is ok
or not.

ok, backported in r64075.
Also backported v.to.rast: (replace custom cell type with raster cell
type; use size_t) and a few other things.

Actual state:

http://trac.osgeo.org/grass/wiki/Grass7Planning
To be clarified:
- v.distance: geodesic support
- v.kernel: Vect_net_shortest_path_coor2() usage
- v.out.ascii: return test in vector/v.out.ascii/main.c
- v.select: various differences
?

Markus

[Markus Metz]

Post by Markus Neteler
On Mon, Jan 12, 2015 at 10:02 AM, Markus Metz
...

Post by Markus Metz

Post by Markus Neteler
* checks for Vect_open_* return value to avoid potential segmentation
fault: r60054 <<-- wasn't the idea to avoid these ugly tests in G7?

The Vect_open_* return the open level when opening existing maps, not
just success or failure. Some modules, most importantly v.info, try to
open a map first with topology, if that fails, without topology.
Therefore it is up to the modules to decide if the return code is ok
or not.

ok, backported in r64075.
Also backported v.to.rast: (replace custom cell type with raster cell
type; use size_t) and a few other things.
http://trac.osgeo.org/grass/wiki/Grass7Planning
- v.distance: geodesic support

backported in r64094,5

Post by Markus Neteler
- v.kernel: Vect_net_shortest_path_coor2() usage

The API changed in G 7.1 because of new turntable support in network analysis.

Post by Markus Neteler
- v.out.ascii: return test in vector/v.out.ascii/main.c

backported in r64096

Post by Markus Neteler
- v.select: various differences

code optimization, no bug fix

Markus M

[Markus Neteler]

On Mon, Jan 12, 2015 at 3:20 PM, Markus Metz
<***@gmail.com> wrote:
...

Post by Markus Metz

Post by Markus Neteler
- v.select: various differences

code optimization, no bug fix

Just to understand: yet not tested enough to be backported?

markusN

[Markus Metz]

Post by Markus Neteler
On Mon, Jan 12, 2015 at 3:20 PM, Markus Metz
...

Post by Markus Metz

Post by Markus Neteler
- v.select: various differences

code optimization, no bug fix

Just to understand: yet not tested enough to be backported?

Optimizations are not high on my priority list of backports. You
tested v.select yourself: the GRASS-internal overlap operator vs. the
GEOS overlaps operator of v.select, in order to select tile coverage
from buffered linear features. The GRASS-internal overlap operator is
more accurate, and processing is faster (after optimization).

Markus M

[Markus Neteler]

Post by Markus Neteler
Hi devs,
proposal for new RC1 release date: 14 Jan 2015.
Let's please manage to keep that date if you agree.
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

The RC1 release is due today :-)
The planning list is looking good to me. And it is not the final but
RC1 release.

If there are no objections, I'll tag later today.

Markus

[Martin Landa]

Hi Markus,

Post by Markus Neteler
The RC1 release is due today :-)
The planning list is looking good to me. And it is not the final but
RC1 release.
If there are no objections, I'll tag later today.

no objections here. Martin

[Moritz Lennert]

Post by Markus Neteler

Post by Markus Neteler
Hi devs,
proposal for new RC1 release date: 14 Jan 2015.
Let's please manage to keep that date if you agree.
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

The RC1 release is due today :-)
The planning list is looking good to me. And it is not the final but
RC1 release.
If there are no objections, I'll tag later today.

Go for it !

Moritz

[Yann Chemin]

+1 Markus !

Post by Moritz Lennert

Post by Markus Neteler

Post by Markus Neteler
Hi devs,
proposal for new RC1 release date: 14 Jan 2015.
Let's please manage to keep that date if you agree.
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

The RC1 release is due today :-)
The planning list is looking good to me. And it is not the final but
RC1 release.
If there are no objections, I'll tag later today.

Go for it !
Moritz
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

... tagging now .... RC1

Markus

[Markus Neteler]

Done!

http://trac.osgeo.org/grass/wiki/Release/7.0.0RC1-News

Now time to announce it...

Markus

[Markus Metz]

Post by Markus Neteler
Done!
http://trac.osgeo.org/grass/wiki/Release/7.0.0RC1-News
Now time to announce it...

Can we please get RC2 out soon? In the last days I have fixed numerous
bugs in the vector library and changed/restored the basic vector IO
interface, it is now more similar to G6 and it needed some code clean
up.

Markus M

[Martin Landa]

Hi,

Post by Markus Metz
Can we please get RC2 out soon? In the last days I have fixed numerous
bugs in the vector library and changed/restored the basic vector IO
interface, it is now more similar to G6 and it needed some code clean
up.

I agree, but would suggest to wait at least one/two week(s), probably
more bugfixes will be collected.

Martin

[Luca Delucchi]

Post by Martin Landa
Hi,

Hi

Post by Martin Landa
I agree, but would suggest to wait at least one/two week(s), probably
more bugfixes will be collected.

+1

Post by Martin Landa
Martin

[Moritz Lennert]

Post by Martin Landa
Hi,

Post by Markus Metz
Can we please get RC2 out soon? In the last days I have fixed numerous
bugs in the vector library and changed/restored the basic vector IO
interface, it is now more similar to G6 and it needed some code clean
up.

Thanks for all this work ! Could you explain a bit more on what types of
bugs this fixed ?

Post by Martin Landa
I agree, but would suggest to wait at least one/two week(s), probably
more bugfixes will be collected.

As these seem to be modifications in fundamental library functions, I
would plead for getting RC2 out more quickly than foreseen, i.e. I'd
plead for 1 week, not 2. That way these modifications will get a bit
more testing before the final release.

This is one example of why the proposed release procedure [1] contains this:

"Any backports during the soft freeze should be announced on the
developers mailing list with 24 hours advance to allow possible discussion."

Maybe this should be extended to "Any backports or extensive bug fixes
during..." ?

If these changes had been announced, we could have delayed RC1 for a few
days...

Moritz

[1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

[Markus Metz]

On Fri, Jan 16, 2015 at 1:27 PM, Moritz Lennert

Post by Moritz Lennert

Post by Martin Landa
Hi,

Post by Markus Metz
Can we please get RC2 out soon? In the last days I have fixed numerous
bugs in the vector library and changed/restored the basic vector IO
interface, it is now more similar to G6 and it needed some code clean
up.

Thanks for all this work ! Could you explain a bit more on what types of
bugs this fixed ?

The first set of bugs was related to vector topology.

Bug 1 affected point-in-polygon tests, a basic geometry function. The
affected functions were Vect_point_in_area(),
Vect_point_in_area_outer_ring() and Vect_point_in_island() which
returned sometimes the wrong result (point outside instead of inside
or vice versa). This in turn affected the functions
Vect_attach_centroids(), Vect_attach_isle() and Vect_attach_isles()
which are needed to update topology when boundaries are added, deleted
or modified.

Bug 2 was in Vect_attach_centroids() andVect_attach_isles(). Centroids
and isles were not properly reattached when boundaries are added,
deleted or modified. These bugs still need to be fixed in G6.

Bugs 1 + 2 meant that (re)attaching centroids and isles during vector
modification was not working well, a fairly important feature for
modifying vector topology.

The modifications related to basic vector IO fixed some bugs
introduced in G7. Some functions were only working with topology, even
though equivalent functions not requiring topology are available. A
newly introduced test prevented access to the non-topological
variants. Further on, some function definitions were changed such that
new arguments were introduced that were not used/not needed. I have
syncronized the IO interface and updated the documentation. It is now
more similar to G6 and some functions have become non-topological
equivalents (interesting for large point clouds).

Post by Moritz Lennert

Post by Martin Landa
I agree, but would suggest to wait at least one/two week(s), probably
more bugfixes will be collected.

As these seem to be modifications in fundamental library functions, I would
plead for getting RC2 out more quickly than foreseen, i.e. I'd plead for 1
week, not 2. That way these modifications will get a bit more testing before
the final release.

I would plead for 1 day rather than 1 week.

Post by Moritz Lennert
"Any backports during the soft freeze should be announced on the developers
mailing list with 24 hours advance to allow possible discussion."
Maybe this should be extended to "Any backports or extensive bug fixes
during..." ?
If these changes had been announced, we could have delayed RC1 for a few
days...

I discovered the bugs only in the last days and tried to get them
fixed as soon as possible, but some of the bugs were rather obscure
and I had no idea how quickly I would be able to find their reason and
fix them. The fixes are all thoroughly tested (I guess I have never
before tested vector topology so thoroughly...).

Markus M

Post by Moritz Lennert
Moritz
[1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

[Yann Chemin]

In view of Markus M explanation, +1 for RC2 today rather than tomorrow.

Post by Markus Metz
On Fri, Jan 16, 2015 at 1:27 PM, Moritz Lennert

Post by Moritz Lennert

Post by Martin Landa
Hi,

Post by Markus Metz
Can we please get RC2 out soon? In the last days I have fixed numerous
bugs in the vector library and changed/restored the basic vector IO
interface, it is now more similar to G6 and it needed some code clean
up.

Thanks for all this work ! Could you explain a bit more on what types of
bugs this fixed ?

The first set of bugs was related to vector topology.
Bug 1 affected point-in-polygon tests, a basic geometry function. The
affected functions were Vect_point_in_area(),
Vect_point_in_area_outer_ring() and Vect_point_in_island() which
returned sometimes the wrong result (point outside instead of inside
or vice versa). This in turn affected the functions
Vect_attach_centroids(), Vect_attach_isle() and Vect_attach_isles()
which are needed to update topology when boundaries are added, deleted
or modified.
Bug 2 was in Vect_attach_centroids() andVect_attach_isles(). Centroids
and isles were not properly reattached when boundaries are added,
deleted or modified. These bugs still need to be fixed in G6.
Bugs 1 + 2 meant that (re)attaching centroids and isles during vector
modification was not working well, a fairly important feature for
modifying vector topology.
The modifications related to basic vector IO fixed some bugs
introduced in G7. Some functions were only working with topology, even
though equivalent functions not requiring topology are available. A
newly introduced test prevented access to the non-topological
variants. Further on, some function definitions were changed such that
new arguments were introduced that were not used/not needed. I have
syncronized the IO interface and updated the documentation. It is now
more similar to G6 and some functions have become non-topological
equivalents (interesting for large point clouds).

Post by Moritz Lennert

Post by Martin Landa
I agree, but would suggest to wait at least one/two week(s), probably
more bugfixes will be collected.

As these seem to be modifications in fundamental library functions, I

would

Post by Moritz Lennert
plead for getting RC2 out more quickly than foreseen, i.e. I'd plead for

1

Post by Moritz Lennert
week, not 2. That way these modifications will get a bit more testing

before

Post by Moritz Lennert
the final release.

I would plead for 1 day rather than 1 week.

Post by Moritz Lennert
This is one example of why the proposed release procedure [1] contains
"Any backports during the soft freeze should be announced on the

developers

Post by Moritz Lennert
mailing list with 24 hours advance to allow possible discussion."
Maybe this should be extended to "Any backports or extensive bug fixes
during..." ?
If these changes had been announced, we could have delayed RC1 for a few
days...

I discovered the bugs only in the last days and tried to get them
fixed as soon as possible, but some of the bugs were rather obscure
and I had no idea how quickly I would be able to find their reason and
fix them. The fixes are all thoroughly tested (I guess I have never
before tested vector topology so thoroughly...).
Markus M

Post by Moritz Lennert
Moritz
[1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Post by Yann Chemin
In view of Markus M explanation, +1 for RC2 today rather than tomorrow.

I don't see any reason why to hurry so much. Let's wait at least some
days. Martin

[Anna Petrášová]

Post by Martin Landa

Post by Yann Chemin
In view of Markus M explanation, +1 for RC2 today rather than tomorrow.

I don't see any reason why to hurry so much. Let's wait at least some
days. Martin

I would like to have RC2 soon too, but let's wait until next week, we will
be able to fix hopefully couple of other things until then. We should have
clearer idea what will be after RC2? How long do we plan to test before
release? I know it will depend on current situation, but still we should
have a plan.

Anna

Post by Martin Landa
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

Post by Anna Petrášová

Post by Martin Landa

Post by Yann Chemin
In view of Markus M explanation, +1 for RC2 today rather than tomorrow.

I don't see any reason why to hurry so much. Let's wait at least some
days. Martin

I would like to have RC2 soon too, but let's wait until next week, we will
be able to fix hopefully couple of other things until then.

We should consider RC2 for later this week.
What's missing for it in terms of fixes?

Post by Anna Petrášová
We should have clearer idea what will be after RC2?

For now I have started to add stuff to
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

Post by Anna Petrášová
How long do we plan to test before
release? I know it will depend on current situation, but still we should
have a plan.

There is a plan:
http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

Markus

[Martin Landa]

Hi,

Post by Moritz Lennert
http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

for GRASS 7.0 I can imagine also RC3 but not more. In any case we are
in hard freeze period now.

Martin

[Moritz Lennert]

Post by Markus Neteler

Post by Anna Petrášová

Post by Martin Landa

Post by Yann Chemin
In view of Markus M explanation, +1 for RC2 today rather than tomorrow.

I don't see any reason why to hurry so much. Let's wait at least some
days. Martin

I would like to have RC2 soon too, but let's wait until next week, we will
be able to fix hopefully couple of other things until then.

We should consider RC2 for later this week.
What's missing for it in terms of fixes?

Post by Anna Petrášová
We should have clearer idea what will be after RC2?

For now I have started to add stuff to
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

Post by Anna Petrášová
How long do we plan to test before
release? I know it will depend on current situation, but still we should
have a plan.

http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

Well, this procedure states that :

"If sufficient support is present, the first announcement is sent by the
Release manager to the developers mailing list about the upcoming
release along with a trac planning page (section). [...] The
announcement should also include an approximate time table for the
release, including the start of hard freeze, RC1, RC2, final release and
the link to the trac page."

Moritz

[Markus Neteler]

On Wed, Jan 21, 2015 at 9:19 AM, Moritz Lennert

Post by Moritz Lennert

Post by Moritz Lennert
http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

"If sufficient support is present, the first announcement is sent by the
Release manager to the developers mailing list about the upcoming release
along with a trac planning page (section). [...] The announcement should
also include an approximate time table for the release, including the start
of hard freeze, RC1, RC2, final release and the link to the trac page."

Well, it is very difficult to predict the final release date. See here
for the undone backports which I have found (indeed, it is the task of
the respective developer to take care of that):

http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing

Excerpt:

- Update Release/7.0.0RC1-News <<- Should it become generic RC News?
- Update Splash screen
- Update Welcome screen

To be backported:
- r64270 raster3d docs
- r64239, r64216 temporal docs
- r64226 XML (?)

Relevant differences - to be clarified:
- various modules: %s= and %s= are mutually exclusive (r?)

All this needs to be solved for RC2.

Markus

[Martin Landa]

Hi,

Post by Markus Neteler
- Update Release/7.0.0RC1-News <<- Should it become generic RC News?

yes, I would vote for generic as we did for betas.

[...]

Martin

[Markus Neteler]

Post by Martin Landa
Hi,

Post by Markus Neteler
- Update Release/7.0.0RC1-News <<- Should it become generic RC News?

yes, I would vote for generic as we did for betas.

Done (with redirect link on old page + updated in CMS):
http://trac.osgeo.org/grass/wiki/Release/7.0.0RC-News

Markus

[Martin Landa]

Post by Markus Neteler
http://trac.osgeo.org/grass/wiki/Release/7.0.0RC-News

thanks, Martin

[Anna Petrášová]

Post by Markus Neteler
On Wed, Jan 21, 2015 at 9:19 AM, Moritz Lennert

Post by Moritz Lennert

Post by Moritz Lennert
http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

"If sufficient support is present, the first announcement is sent by the
Release manager to the developers mailing list about the upcoming release
along with a trac planning page (section). [...] The announcement should
also include an approximate time table for the release, including the

start

Post by Moritz Lennert
of hard freeze, RC1, RC2, final release and the link to the trac page."

Well, it is very difficult to predict the final release date. See here
for the undone backports which I have found (indeed, it is the task of
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
- Update Release/7.0.0RC1-News <<- Should it become generic RC News?
- Update Splash screen
- Update Welcome screen
- r64270 raster3d docs
- r64239, r64216 temporal docs
- r64226 XML (?)
- various modules: %s= and %s= are mutually exclusive (r?)

I am not sure what this last one means, do we know which modules is it
related to?

Anna

Post by Markus Neteler
All this needs to be solved for RC2.
Markus

[Markus Neteler]

Post by Anna Petrášová

Post by Markus Neteler
Well, it is very difficult to predict the final release date. See here
for the undone backports which I have found (indeed, it is the task of
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
- Update Release/7.0.0RC1-News <<- Should it become generic RC News?
- Update Splash screen
- Update Welcome screen
- r64270 raster3d docs
- r64239, r64216 temporal docs
- r64226 XML (?)
- various modules: %s= and %s= are mutually exclusive (r?)

I am not sure what this last one means, do we know which modules is it
related to?

This change (and related) has not been backported so far (I understand
that it is a relevant patch):

http://trac.osgeo.org/grass/changeset/60703

1. Consolite option/flag mutually exslusive messages.

%s= and %s= are mutually exclusive
%s= and %s= are mutually exclusive. %s= will be ignored.
%s= and %s=/%s= are mutually exclusive
%s=, %s=, %s= and %s= are mutually exclusive.
%s=, %s= and %s= are mutually exclusive
-%c and %s= are mutually exclusive
-%c and -%c are mutually exclusive
-%c, -%c, %s=, %s= and %s= are mutually exclusive
-%c/-%c and %s= are mutually exclusive
-%c/-%c and %s=%s are mutually exclusive
-%c/-%c and -%c are mutually exclusive

2. Option(s) <opt>, ... => opt=, ...
3. Flag(s) -f, ... => -f, ...


Markus

[Moritz Lennert]

Post by Markus Neteler

Post by Anna Petrášová

Post by Markus Neteler
Well, it is very difficult to predict the final release date. See here
for the undone backports which I have found (indeed, it is the task of
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
- Update Release/7.0.0RC1-News <<- Should it become generic RC News?
- Update Splash screen
- Update Welcome screen
- r64270 raster3d docs
- r64239, r64216 temporal docs
- r64226 XML (?)
- various modules: %s= and %s= are mutually exclusive (r?)

I am not sure what this last one means, do we know which modules is it
related to?

This change (and related) has not been backported so far (I understand
http://trac.osgeo.org/grass/changeset/60703
1. Consolite option/flag mutually exslusive messages.
%s= and %s= are mutually exclusive
%s= and %s= are mutually exclusive. %s= will be ignored.
%s= and %s=/%s= are mutually exclusive
%s=, %s=, %s= and %s= are mutually exclusive.
%s=, %s= and %s= are mutually exclusive
-%c and %s= are mutually exclusive
-%c and -%c are mutually exclusive
-%c, -%c, %s=, %s= and %s= are mutually exclusive
-%c/-%c and %s= are mutually exclusive
-%c/-%c and %s=%s are mutually exclusive
-%c/-%c and -%c are mutually exclusive
2. Option(s) <opt>, ... => opt=, ...
3. Flag(s) -f, ... => -f, ...

Shouldn't this be handled by the new exlusive / dependent / etc settings
for the parser ? With a message from the parser in case of issues ?

Moritz

[Anna Petrášová]

On Thu, Jan 22, 2015 at 5:43 AM, Moritz Lennert <

Post by Moritz Lennert

Post by Markus Neteler

Post by Anna Petrášová

Post by Markus Neteler
Well, it is very difficult to predict the final release date. See here
for the undone backports which I have found (indeed, it is the task of
http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
- Update Release/7.0.0RC1-News <<- Should it become generic RC News?
- Update Splash screen
- Update Welcome screen
- r64270 raster3d docs
- r64239, r64216 temporal docs
- r64226 XML (?)
- various modules: %s= and %s= are mutually exclusive (r?)

I am not sure what this last one means, do we know which modules is it
related to?

This change (and related) has not been backported so far (I understand
http://trac.osgeo.org/grass/changeset/60703
1. Consolite option/flag mutually exslusive messages.
%s= and %s= are mutually exclusive
%s= and %s= are mutually exclusive. %s= will be ignored.
%s= and %s=/%s= are mutually exclusive
%s=, %s=, %s= and %s= are mutually exclusive.
%s=, %s= and %s= are mutually exclusive
-%c and %s= are mutually exclusive
-%c and -%c are mutually exclusive
-%c, -%c, %s=, %s= and %s= are mutually exclusive
-%c/-%c and %s= are mutually exclusive
-%c/-%c and %s=%s are mutually exclusive
-%c/-%c and -%c are mutually exclusive
2. Option(s) <opt>, ... => opt=, ...
3. Flag(s) -f, ... => -f, ...

Shouldn't this be handled by the new exlusive / dependent / etc settings
for the parser ? With a message from the parser in case of issues ?

Yes, they should. But I wouldn't change it to the new system for the
release, from my experience, you can easily make a mistake. But r60703
should be backported (just to avoid unnecessary differences between 70 and
71), I wanted to do that, but there were some conflicts, so I will look at
it later.

Anna

Post by Moritz Lennert
Moritz

[Moritz Lennert]

Post by Markus Neteler
On Wed, Jan 21, 2015 at 9:19 AM, Moritz Lennert

Post by Moritz Lennert

Post by Moritz Lennert
http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

"If sufficient support is present, the first announcement is sent by the
Release manager to the developers mailing list about the upcoming release
along with a trac planning page (section). [...] The announcement should
also include an approximate time table for the release, including the start
of hard freeze, RC1, RC2, final release and the link to the trac page."

Well, it is very difficult to predict the final release date. See here
for the undone backports which I have found (indeed, it is the task of
the respective developer to take care of that)

Coming back to this after a while. I think this is exactly the question:
should we wait until everything is backported, or should we fix a date
and if some things are not backported, they will have to be in the next
point release ?

In the proposed release procedure backports should be done before the
hard freeze and the first RC...

Just to be sure: I'm not criticizing the way the release is handled,
just using this current release to illustrate the ideas of the proposed
release procedure. And some of the experiences of the current release
could maybe feed back into amendments of that proposal.

Moritz

[Markus Neteler]

On Tue, Jan 27, 2015 at 9:46 AM, Moritz Lennert
...

should we wait until everything is backported, or should we fix a date and
if some things are not backported, they will have to be in the next point
release ?

The important blocker is now the welcome screen issue.

In the proposed release procedure backports should be done before the hard
freeze and the first RC...

Sure. But we can definitely not release G7 with a startup identical to G6.
Too bad that nobody cared in the past 2 years but only now.

Just to be sure: I'm not criticizing the way the release is handled, just
using this current release to illustrate the ideas of the proposed release
procedure. And some of the experiences of the current release could maybe
feed back into amendments of that proposal.

Yes, agreed.

Markus

[Moritz Lennert]

Post by Markus Neteler
On Tue, Jan 27, 2015 at 9:46 AM, Moritz Lennert
...

should we wait until everything is backported, or should we fix a date and
if some things are not backported, they will have to be in the next point
release ?

The important blocker is now the welcome screen issue.

In the proposed release procedure backports should be done before the hard
freeze and the first RC...

Sure. But we can definitely not release G7 with a startup identical to G6.
Too bad that nobody cared in the past 2 years but only now.

Well, that's the deadline effect Glynn already spoke about when
discussing the last-minute rush to harmonising option keys [1]. Not much
we can do about this I'm afraid, except maybe creating deadlines more
often ;-)

Moritz

[1] http://trac.osgeo.org/grass/ticket/2409#comment:122

[Vincent Bain]

As far as I can help the startup screen issue, I'll try to make a point
tomorrow on the wiki. There is no doubt a solution can be found in a
couple of days, is there ?

V.

Post by Markus Neteler
On Tue, Jan 27, 2015 at 9:46 AM, Moritz Lennert
...

should we wait until everything is backported, or should we fix a date and
if some things are not backported, they will have to be in the next point
release ?

The important blocker is now the welcome screen issue.

In the proposed release procedure backports should be done before the hard
freeze and the first RC...

Sure. But we can definitely not release G7 with a startup identical to G6.
Too bad that nobody cared in the past 2 years but only now.

Just to be sure: I'm not criticizing the way the release is handled, just
using this current release to illustrate the ideas of the proposed release
procedure. And some of the experiences of the current release could maybe
feed back into amendments of that proposal.

Yes, agreed.
Markus
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Vaclav Petras]

Post by Markus Metz
The fixes are all thoroughly tested (I guess I have never
before tested vector topology so thoroughly...).

Hi Markus,

will you be able to turn your tests into testsuite scripts? It is
additional work but it gives us possibility to ensure that nobody will
break what you did and it should save it your time in the long run.

Let me know if you miss something in testing framework which would help you
to write the tests.

Vaclav

[Markus Metz]

On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz

Post by Markus Metz
The fixes are all thoroughly tested (I guess I have never
before tested vector topology so thoroughly...).

Hi Markus,
will you be able to turn your tests into testsuite scripts? It is additional
work but it gives us possibility to ensure that nobody will break what you
did and it should save it your time in the long run.

I modified v.generalize in my local copy to become a topology
debugging tool. The debugging tools could be activated with an
environment variable which would need to be set by the test suite.

If I turn the tests into a test suite script, I will use a vector from
the the full version of the North Carolina sample dataset. Is this ok?

Let me know if you miss something in testing framework which would help you
to write the tests.

I would like to provide a command and the test suite must check the
return status. If someone else could then turn this into a testsuite
script, that would be great!

Markus M

[Vaclav Petras]

Post by Vaclav Petras

On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz

Post by Markus Metz
The fixes are all thoroughly tested (I guess I have never
before tested vector topology so thoroughly...).

Hi Markus,
will you be able to turn your tests into testsuite scripts? It is

additional

work but it gives us possibility to ensure that nobody will break what

you

did and it should save it your time in the long run.

I modified v.generalize in my local copy to become a topology
debugging tool. The debugging tools could be activated with an
environment variable which would need to be set by the test suite.
Setting environmental variable should be easy in the test suite. I'm not

sure about the v.generalize modification. Topology debugging tool sound's
generally useful. Perhaps it could be part of v.generalize interface or a
standalone module (build with v.generalize in the same way as r.colors and
r3.colors are) but for tests it really doesn't matter.

If I turn the tests into a test suite script, I will use a vector from

Post by Vaclav Petras
the the full version of the North Carolina sample dataset. Is this ok?

This is ok. MarkusN says we should use the new dataset but I think it is
not yet stable.

Post by Vaclav Petras

Let me know if you miss something in testing framework which would help

you

to write the tests.

I would like to provide a command and the test suite must check the
return status. If someone else could then turn this into a testsuite
script, that would be great!
Any .sh or .py script you put to testsuite directory anywhere in GRASS

source code will be executed as test, so in your case, it should be enough
just to put the command to .sh file together with the appropriate export
command for the environmental variable. I'm afraid this feature is not
really documented (except for emails) because I did it in last minute and
it is not the best practice. Anyway, posting command is fine if the only
thing needed is to check return status.

Vaclav

Markus M

[Markus Neteler]

Post by Vaclav Petras

Post by Markus Metz
I modified v.generalize in my local copy to become a topology
debugging tool. The debugging tools could be activated with an
environment variable which would need to be set by the test suite.

This sounds pretty cool to have.

Post by Vaclav Petras
Setting environmental variable should be easy in the test suite. I'm not
sure about the v.generalize modification. Topology debugging tool sound's
generally useful. Perhaps it could be part of v.generalize interface or a
standalone module (build with v.generalize in the same way as r.colors and
r3.colors are) but for tests it really doesn't matter.

If that would be possible: perfect solution.

Post by Vaclav Petras

Post by Markus Metz
If I turn the tests into a test suite script, I will use a vector from
the the full version of the North Carolina sample dataset. Is this ok?

This is ok. MarkusN says we should use the new dataset but I think it is not
yet stable.

I would invite everybody to switch to these simplified names:
http://trac.osgeo.org/grass/wiki/SampleDataset

At page bottom download the dataset (done by Helena).

markusN

[Vaclav Petras]

Post by Markus Neteler

Post by Vaclav Petras

Post by Markus Metz
If I turn the tests into a test suite script, I will use a vector from
the the full version of the North Carolina sample dataset. Is this ok?

This is ok. MarkusN says we should use the new dataset but I think it is

not

Post by Vaclav Petras
yet stable.

http://trac.osgeo.org/grass/wiki/SampleDataset
At page bottom download the dataset (done by Helena).

Is it stable enough? Anyway, first we have to solve the challenge of having
the maps in different mapsets. How do you get them in examples and tests?
Use name of mapset? Or expect everything to be on path?

Once we decide to switch (for example in 7.1/trunk) we should do it
officially, so we avoid the unclear situation caused by full NC and basic
NC where the locations were incompatible and it was not defined which one
to use.

Which data you use when running the tests on you computer is your choice,
so you can experiment with any dataset and develop your tests with the
dataset which will be used in the future.

I might be able to improve location handling in tests next month, or at
least add the new NC and basic NC locations to my test server to
accommodate the different tests (before the situation will stabilize).

[Markus Neteler]

Post by Vaclav Petras

Post by Markus Neteler

Post by Vaclav Petras

Post by Markus Metz
If I turn the tests into a test suite script, I will use a vector from
the the full version of the North Carolina sample dataset. Is this ok?

This is ok. MarkusN says we should use the new dataset but I think it is not
yet stable.

http://trac.osgeo.org/grass/wiki/SampleDataset
At page bottom download the dataset (done by Helena).

Is it stable enough?

What is "stable"? The names, the size of the package or the selection of maps?

Post by Vaclav Petras
Anyway, first we have to solve the challenge of having
the maps in different mapsets. How do you get them in examples and tests?
Use name of mapset? Or expect everything to be on path?

Probably a simple "g.mapsets" call would be enough to get it in.

Post by Vaclav Petras
Once we decide to switch (for example in 7.1/trunk) we should do it
officially, so we avoid the unclear situation caused by full NC and basic NC
where the locations were incompatible and it was not defined which one to
use.

I haven't used NC basic at all but would be happy to replace (all) my
examples from full NC with the simplified names.

Post by Vaclav Petras
Which data you use when running the tests on you computer is your choice, so
you can experiment with any dataset and develop your tests with the dataset
which will be used in the future.

Yes but the point is that we need to switch to the simplified names as
suggested by Helena (maybe with your collaboration in your lab):
http://trac.osgeo.org/grass/wiki/SampleDataset

At this point I could update the "Piemonte" location (also on the Web
site) accordingly.

Post by Vaclav Petras
I might be able to improve location handling in tests next month, or at
least add the new NC and basic NC locations to my test server to accommodate
the different tests (before the situation will stabilize).

I am not sure what we are waiting for.

Markus

[Vaclav Petras]

Post by Markus Neteler

Post by Vaclav Petras

Post by Markus Neteler

Post by Vaclav Petras

Post by Markus Metz
If I turn the tests into a test suite script, I will use a vector

from

Post by Vaclav Petras

Post by Markus Neteler

Post by Vaclav Petras

Post by Markus Metz
the the full version of the North Carolina sample dataset. Is this

ok?

Post by Vaclav Petras

Post by Markus Neteler

Post by Vaclav Petras
This is ok. MarkusN says we should use the new dataset but I think it

is

Post by Vaclav Petras

Post by Markus Neteler

Post by Vaclav Petras
not
yet stable.

http://trac.osgeo.org/grass/wiki/SampleDataset
At page bottom download the dataset (done by Helena).

Is it stable enough?

What is "stable"? The names, the size of the package or the selection of maps?
Naming, selection and placement into mapsets.

Post by Vaclav Petras
Anyway, first we have to solve the challenge of having
the maps in different mapsets. How do you get them in examples and tests?
Use name of mapset? Or expect everything to be on path?

Probably a simple "g.mapsets" call would be enough to get it in.
Switching of mapset is not applicable in tests (tests are isolated using

GRASS means, i.e. processes and mapsets) but yes, changing path is the way.
Do you think we should add it to each example which needs it? For tests it
would be quite easy to do something like set up the search path
automatically according to existing mapsets or search path set in PERMANENT
but it is desired? I don't have a strong opinion, explicit g.mapsets calls
sounds as a safe way to go but putting @mapsetname everywhere would also
work, am I right?

Post by Markus Neteler
Once we decide to switch (for example in 7.1/trunk) we should do it

Post by Vaclav Petras
officially, so we avoid the unclear situation caused by full NC and

basic NC

Post by Vaclav Petras
where the locations were incompatible and it was not defined which one to
use.

I haven't used NC basic at all but would be happy to replace (all) my
examples from full NC with the simplified names.
It's completely the same for me.

Post by Vaclav Petras
Which data you use when running the tests on you computer is your

choice, so

Post by Vaclav Petras
you can experiment with any dataset and develop your tests with the

dataset

Post by Vaclav Petras
which will be used in the future.

Yes but the point is that we need to switch to the simplified names as
http://trac.osgeo.org/grass/wiki/SampleDataset
At this point I could update the "Piemonte" location (also on the Web
site) accordingly.
Replacing the old one by a new one on my server should be quite simple

because it is already there. Same if we decide to just use new NC instead
of currently used full NC. Adding new location is what is very unpleasant
to do now.

Post by Markus Neteler

Post by Vaclav Petras
I might be able to improve location handling in tests next month, or at
least add the new NC and basic NC locations to my test server to

accommodate

Post by Vaclav Petras
the different tests (before the situation will stabilize).

I am not sure what we are waiting for.
If it is stable enough for trunk (i.e. it is worth to modify examples and

tests) and it is clear how to access the maps in other mapsets then we just
have to announce the official switch. Will this be the default dataset for
7.1 then?

Vaclav

Markus

[Helena Mitasova]

Post by Markus Neteler

Post by Vaclav Petras

Post by Markus Neteler

Post by Vaclav Petras

Post by Markus Metz
If I turn the tests into a test suite script, I will use a vector from
the the full version of the North Carolina sample dataset. Is this ok?

This is ok. MarkusN says we should use the new dataset but I think it is not
yet stable.

http://trac.osgeo.org/grass/wiki/SampleDataset
At page bottom download the dataset (done by Helena).

Is it stable enough?

What is "stable"? The names, the size of the package or the selection of maps?

There is one thing about this data set that I would like to change - the name of the location itself.
Given that distribution of data by mapsets does not work well, all data sets should be distributed as locations
(or external data) and then we won't need the loc part in the name.
So I suggest to use the name

ncspm_baseline_v1.0
or
ncarolina_baseline_v1.0

instead of loc_ncspm_baseline

and we should have a single place where this data set is stored (on grass website under data?)
to avoid creating multiple versions of the data set. I will remove mine and replace it by a link.

Then the italian version of this data set would be

piemonte_baseline

Post by Markus Neteler
Naming, selection and placement into mapsets.

Post by Vaclav Petras
Anyway, first we have to solve the challenge of having
the maps in different mapsets. How do you get them in examples and tests?
Use name of mapset? Or expect everything to be on path?

Probably a simple "g.mapsets" call would be enough to get it in.

I suggest to distribute all mapsets with at least the baseline data set in PERMANENT. Then you would have to deal with data in different
mapsets (and in fact in different locations) only for the examples where you need to combine data from two or more different
specialized mapsets - for example lidar and networks.

Post by Markus Neteler

Post by Vaclav Petras
Once we decide to switch (for example in 7.1/trunk) we should do it
officially, so we avoid the unclear situation caused by full NC and basic NC
where the locations were incompatible and it was not defined which one to
use.

I haven't used NC basic at all but would be happy to replace (all) my
examples from full NC with the simplified names.
It's completely the same for me.

I agree - we should retire all other small data sets and mark them as retired, although I expect that nc_spm_08 and nc_spm_08_grass7 will be still used for a while.
I will post the relevant notes on my website and in our courses as well.

Post by Markus Neteler

Post by Vaclav Petras
Which data you use when running the tests on you computer is your choice, so
you can experiment with any dataset and develop your tests with the dataset
which will be used in the future.

Yes but the point is that we need to switch to the simplified names as
http://trac.osgeo.org/grass/wiki/SampleDataset
At this point I could update the "Piemonte" location (also on the Web
site) accordingly.
Replacing the old one by a new one on my server should be quite simple because it is already there. Same if we decide to just use new NC instead of currently used full NC. Adding new location is what is very unpleasant to do now.

I agree.

Post by Markus Neteler

Post by Vaclav Petras
I might be able to improve location handling in tests next month, or at
least add the new NC and basic NC locations to my test server to accommodate
the different tests (before the situation will stabilize).

I am not sure what we are waiting for.
If it is stable enough for trunk (i.e. it is worth to modify examples and tests) and it is clear how to access the maps in other mapsets then we just have to announce the official switch. Will this be the default dataset for 7.1 then?

GRASS7.1 would be a good target. I am also working on a new external data set and on locations in other coordinate systems with some limited but hopefully meaningful
map layers in them.

Helena

Post by Markus Neteler
Vaclav
Markus
_______________________________________________
grass-dev mailing list
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Metz]

Post by Markus Neteler
http://trac.osgeo.org/grass/wiki/SampleDataset

I disagree. The baseline dataset should be a subset of the full
dataset. The names in the baseline dataset should be identical to the
names in the full dataset. Otherwise, as it is now, it just creates
confusion for no reason.

Markus M

[Markus Neteler]

Post by Markus Metz

Post by Markus Neteler
http://trac.osgeo.org/grass/wiki/SampleDataset

I disagree. The baseline dataset should be a subset of the full
dataset. The names in the baseline dataset should be identical to the
names in the full dataset. Otherwise, as it is now, it just creates
confusion for no reason.

The point is that the new full dataset will come with simplified names. It
is in preparation for the fourth GRASS GIS book edition.

We should update the track page more...

markusN

[Markus Metz]

Post by Markus Neteler

Post by Markus Metz

Post by Markus Neteler
http://trac.osgeo.org/grass/wiki/SampleDataset

I disagree. The baseline dataset should be a subset of the full
dataset. The names in the baseline dataset should be identical to the
names in the full dataset. Otherwise, as it is now, it just creates
confusion for no reason.

The point is that the new full dataset will come with simplified names. It
is in preparation for the fourth GRASS GIS book edition.

That means we need to update a lot of examples in the man pages of 7.x
including 7.0?

Markus M

Post by Markus Neteler
We should update the track page more...
markusN

[Markus Neteler]

On Tue, Jan 20, 2015 at 10:16 PM, Markus Metz

Post by Markus Metz

Post by Markus Neteler

Post by Markus Metz

Post by Markus Neteler
http://trac.osgeo.org/grass/wiki/SampleDataset

I disagree. The baseline dataset should be a subset of the full
dataset. The names in the baseline dataset should be identical to the
names in the full dataset. Otherwise, as it is now, it just creates
confusion for no reason.

The point is that the new full dataset will come with simplified names. It
is in preparation for the fourth GRASS GIS book edition.

That means we need to update a lot of examples in the man pages of 7.x
including 7.0?

In case yes. I already offer to do the job (a not-so-hard
search/replace operation).
Obviously we need to speed up with this. Or forget about it for 7.0.0.

But mixing nc_full and nc_basic remains a bad idea.

markusN

[Markus Metz]

Post by Vaclav Petras

Post by Markus Metz

On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz

Post by Markus Metz
The fixes are all thoroughly tested (I guess I have never
before tested vector topology so thoroughly...).

Hi Markus,
will you be able to turn your tests into testsuite scripts? It is additional
work but it gives us possibility to ensure that nobody will break what you
did and it should save it your time in the long run.

I modified v.generalize in my local copy to become a topology
debugging tool. The debugging tools could be activated with an
environment variable which would need to be set by the test suite.

Setting environmental variable should be easy in the test suite. I'm not
sure about the v.generalize modification. Topology debugging tool sound's
generally useful. Perhaps it could be part of v.generalize interface or a
standalone module (build with v.generalize in the same way as r.colors and
r3.colors are) but for tests it really doesn't matter.

Post by Markus Metz
If I turn the tests into a test suite script, I will use a vector from
the the full version of the North Carolina sample dataset. Is this ok?

This is ok. MarkusN says we should use the new dataset but I think it is not
yet stable.

Post by Markus Metz

Let me know if you miss something in testing framework which would help you
to write the tests.

I would like to provide a command and the test suite must check the
return status. If someone else could then turn this into a testsuite
script, that would be great!

Any .sh or .py script you put to testsuite directory anywhere in GRASS
source code will be executed as test, so in your case, it should be enough
just to put the command to .sh file together with the appropriate export
command for the environmental variable. I'm afraid this feature is not
really documented (except for emails) because I did it in last minute and it
is not the best practice. Anyway, posting command is fine if the only thing
needed is to check return status.

For nc_spm_08, the test commands would be (as shell script):

g.region -p rast=***@PERMANENT
r.to.vect in=***@PERMANENT out=landuse96_28m type=area
export GRASS_VECTOR_TOPO_DEBUG=1
# check return code of
v.generalize in=landuse96_28m out=landuse96_28m_dp method=douglas threshold=21
if [ $? -ne 0 ] ; then
exit 1
fi

The vectors in the sample datasets are "too good", I did not find a
vector to provoke any errors, thus the r.to.vect step.

Real world datasets, particularly vectors with administrative areas or
land cover/land use classification, are in this respect more suitable
because they contain lots of topological errors. Unfortunately, these
datasets are too large to be included in the sample datasets.

Markus M

Post by Vaclav Petras
Vaclav

Post by Markus Metz
Markus M

[Vaclav Petras]

Post by Markus Neteler

On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz <

Post by Markus Metz

On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz

Post by Markus Metz
The fixes are all thoroughly tested (I guess I have never
before tested vector topology so thoroughly...).

Hi Markus,
will you be able to turn your tests into testsuite scripts? It is additional
work but it gives us possibility to ensure that nobody will break what you
did and it should save it your time in the long run.

I modified v.generalize in my local copy to become a topology
debugging tool. The debugging tools could be activated with an
environment variable which would need to be set by the test suite.

Setting environmental variable should be easy in the test suite. I'm not
sure about the v.generalize modification. Topology debugging tool sound's
generally useful. Perhaps it could be part of v.generalize interface or a
standalone module (build with v.generalize in the same way as r.colors

and

r3.colors are) but for tests it really doesn't matter.

Post by Markus Metz
If I turn the tests into a test suite script, I will use a vector from
the the full version of the North Carolina sample dataset. Is this ok?

This is ok. MarkusN says we should use the new dataset but I think it is

not

yet stable.

Post by Markus Metz

Let me know if you miss something in testing framework which would

help

Post by Markus Metz

you
to write the tests.

I would like to provide a command and the test suite must check the
return status. If someone else could then turn this into a testsuite
script, that would be great!

Any .sh or .py script you put to testsuite directory anywhere in GRASS
source code will be executed as test, so in your case, it should be

enough

just to put the command to .sh file together with the appropriate export
command for the environmental variable. I'm afraid this feature is not
really documented (except for emails) because I did it in last minute

and it

is not the best practice. Anyway, posting command is fine if the only

thing

needed is to check return status.

export GRASS_VECTOR_TOPO_DEBUG=1
# check return code of
v.generalize in=landuse96_28m out=landuse96_28m_dp method=douglas threshold=21
if [ $? -ne 0 ] ; then
exit 1
fi

cd lib/vector/
python -m grass.gunittest.main --location
my_nc_spm_08_grass7_location_for_tests --location-type nc

This will create a proper report from all tests in all testsuite
directories inside the tree starting at lib/vector/. Find the report in
testreport/index.html. Alternatively, execute just the script you want:

cd lib/vector/testsuite/
sh -e -x test_topology_vgeneralize.sh

Running directly would be possible but you want to set -e flag for failing
on the first non-zero return status as it is done inside testing framework
[3].

I was not really sure what it is testing some library things or the
v.generalize debug feature itself. I though the former, so I put it to
lib/vector. Please, move it somewhere else, if it tests something
different. (Test suite directory should be in the directory with tested
code.)

As I said, shell script is not ideal because it will not work on MS Windows
in GRASS GIS 7 unless you install it but it is at least something.
Rewriting to Python would be better and actually not so difficult if only
plain Python is used but this would still miss the advantages of the
testing framework. Rewriting using gunittest is relatively simple too but I
just don't have time to do that.

Vaclav

[1] http://trac.osgeo.org/grass/changeset/64269
[2]
http://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#testing-with-gunittest-package-in-general
[3]
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest/invoker.py?rev=62358#L148

Post by Markus Neteler
The vectors in the sample datasets are "too good", I did not find a
vector to provoke any errors, thus the r.to.vect step.
Real world datasets, particularly vectors with administrative areas or
land cover/land use classification, are in this respect more suitable
because they contain lots of topological errors. Unfortunately, these
datasets are too large to be included in the sample datasets.

Markus M

Post by Markus Neteler

Vaclav

Post by Markus Metz
Markus M

[Markus Metz]

Post by Markus Metz

On Sat, Jan 17, 2015 at 2:40 PM, Markus Metz

Post by Markus Metz

On Fri, Jan 16, 2015 at 10:01 AM, Markus Metz

Post by Markus Metz
The fixes are all thoroughly tested (I guess I have never
before tested vector topology so thoroughly...).

Hi Markus,
will you be able to turn your tests into testsuite scripts? It is additional
work but it gives us possibility to ensure that nobody will break what
you
did and it should save it your time in the long run.

I modified v.generalize in my local copy to become a topology
debugging tool. The debugging tools could be activated with an
environment variable which would need to be set by the test suite.

Setting environmental variable should be easy in the test suite. I'm not
sure about the v.generalize modification. Topology debugging tool sound's
generally useful. Perhaps it could be part of v.generalize interface or a
standalone module (build with v.generalize in the same way as r.colors and
r3.colors are) but for tests it really doesn't matter.

Post by Markus Metz
If I turn the tests into a test suite script, I will use a vector from
the the full version of the North Carolina sample dataset. Is this ok?

This is ok. MarkusN says we should use the new dataset but I think it is not
yet stable.

Post by Markus Metz

Let me know if you miss something in testing framework which would help
you
to write the tests.

I would like to provide a command and the test suite must check the
return status. If someone else could then turn this into a testsuite
script, that would be great!

Any .sh or .py script you put to testsuite directory anywhere in GRASS
source code will be executed as test, so in your case, it should be enough
just to put the command to .sh file together with the appropriate export
command for the environmental variable. I'm afraid this feature is not
really documented (except for emails) because I did it in last minute and it
is not the best practice. Anyway, posting command is fine if the only thing
needed is to check return status.

export GRASS_VECTOR_TOPO_DEBUG=1
# check return code of
v.generalize in=landuse96_28m out=landuse96_28m_dp method=douglas threshold=21
if [ $? -ne 0 ] ; then
exit 1
fi

Done in r64269 [1].

Thanks.

cd lib/vector/
python -m grass.gunittest.main --location
my_nc_spm_08_grass7_location_for_tests --location-type nc
This will create a proper report from all tests in all testsuite directories
inside the tree starting at lib/vector/. Find the report in
cd lib/vector/testsuite/
sh -e -x test_topology_vgeneralize.sh
Running directly would be possible but you want to set -e flag for failing
on the first non-zero return status as it is done inside testing framework
[3].
I was not really sure what it is testing some library things or the
v.generalize debug feature itself. I though the former, so I put it to
lib/vector. Please, move it somewhere else, if it tests something different.
(Test suite directory should be in the directory with tested code.)

It tests some library things and just uses v.generalize to do
modifications, thus putting it in lib/vector is fine.

Markus M

As I said, shell script is not ideal because it will not work on MS Windows
in GRASS GIS 7 unless you install it but it is at least something. Rewriting
to Python would be better and actually not so difficult if only plain Python
is used but this would still miss the advantages of the testing framework.
Rewriting using gunittest is relatively simple too but I just don't have
time to do that.
Vaclav
[1] http://trac.osgeo.org/grass/changeset/64269
[2]
http://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#testing-with-gunittest-package-in-general
[3]
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/gunittest/invoker.py?rev=62358#L148

Post by Markus Metz
The vectors in the sample datasets are "too good", I did not find a
vector to provoke any errors, thus the r.to.vect step.
Real world datasets, particularly vectors with administrative areas or
land cover/land use classification, are in this respect more suitable
because they contain lots of topological errors. Unfortunately, these
datasets are too large to be included in the sample datasets.
Markus M

Vaclav

Post by Markus Metz
Markus M

[Martin Landa]

Hi Markus,

Post by Markus Neteler
... tagging now .... RC1

perfect, thanks! Martin

[Martin Landa]

Post by Markus Neteler
- lib/vector/Vlib/ascii.c

its [1,2] - I would leave decision to Markus Metz. Martin

[1] http://trac.osgeo.org/grass/changeset/63596/grass/trunk/lib/vector/Vlib/ascii.c
[2] http://trac.osgeo.org/grass/changeset/63599/grass/trunk/lib/vector/Vlib/ascii.c

[Martin Landa]

Post by Markus Neteler
- lib/vector/Vlib/build.c

it's [1], decision should be ideally done by MarkusM.

Martin

[1] http://trac.osgeo.org/grass/changeset/61492/grass/trunk/lib/vector/Vlib/build.c

[Martin Landa]

Post by Markus Neteler
- lib/vector/Vlib/line.c

it's [1], MarkusM.

Martin

[1] http://trac.osgeo.org/grass/changeset/61978/grass/trunk/lib/vector/Vlib/line.c

[Martin Landa]

Post by Markus Neteler
- lib/vector/Vlib/map.c

solved in r63932. Martin

[Martin Landa]

Post by Markus Neteler
- lib/vector/Vlib/read_pg.c

done in r63933. Martin

[Martin Landa]

Post by Markus Neteler
- lib/vector/Vlib/remove_areas.c

it's [1], should be ideally decided by MarkusM.

Martin

[1] http://trac.osgeo.org/grass/changeset/61491/grass/trunk/lib/vector/Vlib/remove_areas.c

[Martin Landa]

Post by Markus Neteler
- lib/vector/Vlib/snap.c

new kdtree implementation by MarkusM [1,2,3]. Probably new feature for
GRASS 7.1 (do not backport) ?

Martin

[1] http://trac.osgeo.org/grass/changeset/63601/grass/trunk/lib/vector/Vlib/snap.c
[2] http://trac.osgeo.org/grass/changeset/63645/grass/trunk/lib/vector/Vlib/snap.c
[3] http://trac.osgeo.org/grass/changeset/63918/grass/trunk/lib/vector/Vlib/snap.c

[Martin Landa]

Post by Markus Neteler
- lib/vector/Vlib/write_nat.c

it's [1], probably backport, I will leave decision on MarkusM. Martin

[1] http://trac.osgeo.org/grass/changeset/63404/grass/trunk/lib/vector/Vlib/write_nat.c