r65519 temporal library: Store the default database connection as shell variable substitute to avoid wrong temporal database path’s in cases the location was renamed or the path to the grass database changed.
I didn’t go through myself yet, but the respective authors may please comment (or just do it).
r64877 - grass/trunk/raster/r.patch: call Rast_cell_size just once, not for
every cell
r62162 - vector/v.generalize: add test for self-intersection, use
Vect_line_intersection2()
r64404 - libpython: move cmd list <-> tuple from wxGUI
r64406 - wxGUI: replace utils cmd list <-> tuple by grass.script.gtask
functions
What is the status of r65057, #2626, #2627, #2628, #2147 and #2655?
r65634 wxGUI source code compatibility
r65519 temporal library: Store the default database connection as shell
variable substitute to avoid wrong temporal database path's in cases the
location was renamed or the path to the grass database changed.
I didn't go through myself yet, but the respective authors may please
comment (or just do it).
- r64877 - grass/trunk/raster/r.patch: call Rast_cell_size just once,
not for every cell: speedup - Author: wenzeslaus Date: 2015-03-16
- r62162 - vector/v.generalize: add test for self-intersection, use
Vect_line_intersection2() - Author: mmetz Oct 2, 2014
- r64404 - libpython: move cmd list <-> tuple from wxGUI: martinl
Date: Feb 2, 2015
- r64406 - wxGUI: replace utils cmd list <-> tuple by
grass.script.gtask functions
- What is the status of r65057 (db.login hostname and port), #2628
(db.login password), #2626 (v.out.ogr and DB), #2627 (v.out.postgis
password), #2147 (db.databases)?
- r65634 (wxGUI: move import/export dialogs from gui_core to modules -
wxGUI source code compatibility) - No idea?
- r65774, r66129 - remove 'display map' tool - ?? not backported to
far. Out of scope?
2015-10-03 10:45 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
- r64404 - libpython: move cmd list <-> tuple from wxGUI: martinl
Date: Feb 2, 2015
- r64406 - wxGUI: replace utils cmd list <-> tuple by
grass.script.gtask functions
- r65634 (wxGUI: move import/export dialogs from gui_core to modules -
wxGUI source code compatibility) - No idea?
not sure, these changes don't fix anything in wxGUI. My suggestion is
to skip backport and focus on trunk development which should lead to
7.1 release (spring 2016?). The code inconsistency between branches
can complicate backporting, but I would not expect so many backports.
Any opinion?
- r65774, r66129 - remove 'display map' tool - ?? not backported to
far. Out of scope?
I would suggest to keep 'display map' tool in 7.0. It's not bugfix.
Let's try to backport only bugfixes and minor issues (keywords, ...).
On Sat, Oct 3, 2015 at 11:01 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2015-10-03 10:45 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
- r64404 - libpython: move cmd list <-> tuple from wxGUI: martinl
Date: Feb 2, 2015
- r64406 - wxGUI: replace utils cmd list <-> tuple by
grass.script.gtask functions
- r65634 (wxGUI: move import/export dialogs from gui_core to modules -
wxGUI source code compatibility) - No idea?
not sure, these changes don't fix anything in wxGUI. My suggestion is
to skip backport and focus on trunk development which should lead to
7.1 release (spring 2016?). The code inconsistency between branches
can complicate backporting, but I would not expect so many backports.
Any opinion?
- r65774, r66129 - remove 'display map' tool - ?? not backported to
far. Out of scope?
I would suggest to keep 'display map' tool in 7.0. It's not bugfix.
Let's try to backport only bugfixes and minor issues (keywords, ...).
ok - just update the trac page then and drop it or move to a later
release number.
I'm not able to judge the wx* changes at all.
2015-10-03 10:45 GMT+02:00 Markus Neteler <neteler@osgeo.org>:
- r64404 - libpython: move cmd list <-> tuple from wxGUI: martinl
Date: Feb 2, 2015
- r64406 - wxGUI: replace utils cmd list <-> tuple by
grass.script.gtask functions
- r65634 (wxGUI: move import/export dialogs from gui_core to modules -
wxGUI source code compatibility) - No idea?
not sure, these changes don't fix anything in wxGUI. My suggestion is
to skip backport and focus on trunk development which should lead to
7.1 release (spring 2016?). The code inconsistency between branches
can complicate backporting, but I would not expect so many backports.
Any opinion?
r64404 - libpython: move cmd list ↔ tuple from wxGUI: martinl
Date: Feb 2, 2015
r64406 - wxGUI: replace utils cmd list ↔ tuple by
grass.script.gtask functions
r65634 (wxGUI: move import/export dialogs from gui_core to modules -
wxGUI source code compatibility) - No idea?
not sure, these changes don’t fix anything in wxGUI. My suggestion is
to skip backport and focus on trunk development which should lead to
7.1 release (spring 2016?). The code inconsistency between branches
can complicate backporting, but I would not expect so many backports.
Any opinion?
+1
+1
Moving code around is good but should not be backported since it has often unforeseen consequences (for example the data catalog changes).
2015-10-03 18:10 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:
+1
Moving code around is good but should not be backported since it has often
unforeseen consequences (for example the data catalog changes).
agreed. To solve the last issues [1]:
* @Vaclav could you take a look at: r64877 ?
* r62162 - there are some conflicts, any opinion - backport or not ?
* What is the status of r65057 - not clear, issues are not solved in
trunk. I event think that none of them should be backported. Let's
focus on 7.1 release.
I added 2 different tests to trunk in r66449 (with manually created results, so they doesn’t depend on the current or previous implementation). I also checked the results with int data when I did r64877, but since then I used r.patch only once or twice with float data. Anyway, it seems safe to backport, so I did that in r66450.
BTW, a nice test for r.patch could be written using random data and comparison of the result with r.mapcalc. This is a good topic for anybody interested in contributing a test.
Moving code around is good but should not be backported since it has often
unforeseen consequences (for example the data catalog changes).
agreed. To solve the last issues [1]:
@Vaclav could you take a look at: r64877 ?
r62162 - there are some conflicts, any opinion - backport or not ?
What is the status of r65057 - not clear, issues are not solved in
trunk. I event think that none of them should be backported. Let’s
focus on 7.1 release.
what about r.import/v.import? I would like to have them in 7.0.2. It wouldn’t influence anything. The related changes in the gui would be for 7.1. Then we could remove them from addons. We don’t have to advertise them too much yet and keep testing, but it would simplify things to have them in releasebranch.
2015-10-09 20:22 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
what about r.import/v.import? I would like to have them in 7.0.2. It
wouldn't influence anything. The related changes in the gui would be for
7.1. Then we could remove them from addons. We don't have to advertise them
too much yet and keep testing, but it would simplify things to have them in
releasebranch.
On Fri, Oct 9, 2015 at 9:47 AM, Martin Landa <landa.martin@gmail.com
<mailto:landa.martin@gmail.com>> wrote:
Hi,
2015-10-03 18:10 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com
<mailto:wenzeslaus@gmail.com>>:
> +1
>
> Moving code around is good but should not be backported since it has often
> unforeseen consequences (for example the data catalog changes).
agreed. To solve the last issues [1]:
* @Vaclav could you take a look at: r64877 ?
* r62162 - there are some conflicts, any opinion - backport or not ?
* What is the status of r65057 - not clear, issues are not solved in
trunk. I event think that none of them should be backported. Let's
focus on 7.1 release.
what about r.import/v.import? I would like to have them in 7.0.2. It
wouldn't influence anything. The related changes in the gui would be
for 7.1. Then we could remove them from addons. We don't have to
advertise them too much yet and keep testing, but it would simplify
things to have them in releasebranch.
On Sat, Oct 10, 2015 at 3:27 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 09/10/15 20:22, Anna Petrášová wrote:
what about r.import/v.import? I would like to have them in 7.0.2.
Yes, me too!
It wouldn't influence anything. The related changes in the gui would be
for 7.1. Then we could remove them from addons. We don't have to
advertise them too much yet and keep testing, but it would simplify
things to have them in releasebranch.
On Sat, Oct 10, 2015 at 12:55 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Sat, Oct 10, 2015 at 3:27 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
> On 09/10/15 20:22, Anna Petrášová wrote:
>> what about r.import/v.import? I would like to have them in 7.0.2.
Yes, me too!
>> It wouldn't influence anything. The related changes in the gui would be
>> for 7.1. Then we could remove them from addons. We don't have to
>> advertise them too much yet and keep testing, but it would simplify
>> things to have them in releasebranch.
>
>
> +1
On Sat, Oct 10, 2015 at 12:58 PM, Anna Petrášová <kratochanna@gmail.com>
wrote:
On Sat, Oct 10, 2015 at 12:55 PM, Markus Neteler <neteler@osgeo.org>
wrote:
On Sat, Oct 10, 2015 at 3:27 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
> On 09/10/15 20:22, Anna Petrášová wrote:
>> what about r.import/v.import? I would like to have them in 7.0.2.
Yes, me too!
>> It wouldn't influence anything. The related changes in the gui would
be
>> for 7.1. Then we could remove them from addons. We don't have to
>> advertise them too much yet and keep testing, but it would simplify
>> things to have them in releasebranch.
>
>
> +1
+1
I'll do it.
Anna
I moved them to releasebranch, some testing is welcome of course. I would
remove them from addons probably after the release?
Anna
