[GRASS-dev] [GRASS-SVN] r68140 - in grass/trunk/scripts: d.correlate d.frame d.polar d.rast.edit d.rast.leg d.redraw db.dropcolumn db.in.ogr db.out.ogr db.test db.univar g.extension g.extension/testsuite g.extension.all g.manual g.search.modules g.search.modules/testsuite i.colors.enhance i.image.mosaic i.in.spotvgt i.oif i.spectral i.tasscap m.proj r.blend r.buffer.lowmem r.colors.stddev r.fillnulls r.grow r.import r.in.aster r.in.srtm r.in.wms r.mask r.out.xyz r.pack r.plane r.reclass.area r.shade r.tileset r.unpack r3.in.xyz v.build.all v.centroids v.db.addcolumn v.db.addtable v.db.dropcolumn v.db.droprow v.db.droptable v.db.join v.db.reconnect.all v.db.renamecolumn v.db.univar v.db.update v.dissolve v.import v.in.e00 v.in.geonames v.in.lines v.in.mapgen v.in.wfs v.krige v.pack v.rast.stats v.rast.stats/testsuite v.report v.unpack v.what.strds v.what.strds/testsuite wxpyimgview

[Martin Landa]

Hi,

2016-03-30 16:26 GMT+02:00 Markus Neteler <neteler at osgeo.org>:
>>> Indeed there were no discussion, feel free to revert.
>>>
>>> I'm still confused... when can I break the trunk branch? :-)
>
> Trunk may be broken according to our rules.
> And Pietro's contributions are usually outstanding, so I am not quite scared! :)

my major concern - such commits makes backporting much more
complicated. It was reason why I suggest to wait a bit and do such
changes (and other similar) before we create releasebranch_7_2. Then
backporting (trunk -> relbr_72) will be possible.

If you think that it make sense to do this change in trunk now than I
am not against.

> Well, trunk is yet trunk and we did not freeze anything.
> The Python3 compatibility is quite important and a PITA to introduce a
> week after creating the 7.2. branch ;)

I meant week/day BEFORE creating relbr72. So to get this changes into
the next release branch.

Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa