[GRASS-dev] could r.cost nearest option be backported to G6?

Hamish hamish_b at yahoo.com
Wed Feb 27 12:18:27 PST 2013


Margherita wrote:
> A group of colleagues need to use for several runs r.cost with
> the really useful option "nearest" (Name for output raster map
> with nearest start point) which is present in GRASS7.

could someone put some info about what that does in the g7 help
page? It would be nice to expand the r.cost page in the wiki too,
with tips and tricks + screenshots.
  http://grasswiki.osgeo.org/wiki/Cost_surfaces


> The problem is that for some reasons they can't install G7 but
> have to keep working for the moment on G6. Would it be too
> bloody to backport in G6 this nice option?

It is too late to put anything new in for 6.4.3 without risking
unintended consequences (important bug fixes only please). if it
were to happen the way would be to backport it to devbr6 (could
happen now) and make sure that it is all working, then once 6.4.3
is released and the backport to debr6 is tested ok, then it could
go into the 6.4.4svn for wider testing, ie without relbr64
becoming an experimental branch.

/swerve
In any case, direct backports to relbr64 from trunk are dangerous
and they should be avoided, especially just before a release, and
especially for a really important module. Yes it's slightly more
work for devs* than backporting directly from trunk. Yes it
protects users from bugs in code labeled "stable", and so our
hard fought reputation for having a super-dependable core. Even
if only in a small way, it is much better than nothing.


[*] if it is useful to anyone I just commited some of my little
helper shortcut scripts to grass-addons/tools/, which makes
merging recent changes between branches very simple.


best,
Hamish


More information about the grass-dev mailing list