[GRASS-dev] GRASS GIS 7.0.1 planning: potential backports

[Markus Neteler]

On Mon, Jun 8, 2015 at 8:51 AM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> 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.

+1 also here

>> 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.

..  I just locally backported, it also needs
https://trac.osgeo.org/grass/changeset/62045


>> 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.

Agreed.

Markus