[GRASS-dev] GRASS GIS 7.0.1 planning: potential backports
Moritz Lennert
mlennert at club.worldonline.be
Sun Jun 7 23:51:04 PDT 2015
On 07/06/15 23:10, Markus Neteler wrote:
> On Fri, Jun 5, 2015 at 4:17 PM, Martin Landa <landa.martin at gmail.com> wrote:
>> Hi,
>>
>> 2015-06-04 20:55 GMT+02:00 Markus Neteler <neteler at osgeo.org>:
>>> ... please go through the list.
>
> https://trac.osgeo.org/grass/wiki/Grass7Planning#a7.0.1tobebackported
>
> The updated list is now way shorter. I went through a lot of commits
> locally flagged as "backport" in my inbox and also checked those on
> above list.
>
> AFAIK remain now:
>
> r65343 - vector/v.random/main.c: martinl Date: 2015-05-31
I don't see how this can create any problems, and it does solve the one
of having a link to a non-existing table, so I would say +1 for backport.
> r62091 - vector/v.select: speed up OP_OVERLAP - Author: mmetz 2014-09-26
I've only tested this very briefly, but results seem identical and the
speedup is very significant, so I would plead for backport, but MarkusM
should have the last word on this.
> r64834 - lib/python/script/core.py - Author: glynn Date: 2015-03-11
No idea on this particular fix, but I have the feeling that the whole
encoding handling could need a serious overall reflection with a clear
definition of coding rules. AFAIU, at this stage we have different
"solutions" across the code and that none are really satisfactory,
especially as none is really implemented in a global and unified way.
Moritz
More information about the grass-dev
mailing list