[GRASS-dev] GRASS 6.4.3 release planning

[Hamish]

Markus wrote:
> it is about time to get 6.4.3 out of the doors. It would be nice to have
> a RC1 for the upcoming Geostat 2012 in Muenster (full day of GRASS
> teaching).

when is that?

 
> Here is the current state of the art:
> http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=6.4.0
> 
> There are a few blockers which need action but should not be
> a showstopper for RC1.

AFAIAC the few things I would like to fix & consider blockers for
6.4.3 are:

* finish audit of scripts for safe handling of eval `g.gisenv` in case
someone put something they shouldn't in here (like addon path). I already
agreed to look at that.

* related/ ensuring that the gui uses the environment variable for addon
path and not g.gisenv variable. (which besides breaking things is entirely
redundant AFAIK and confusing, just set it in one place, properly) I'm
not sure if that has been backported from devbr6 to releasebranch64 or
not; hopefully not from my POV.

* the ps.map gui composer in unreleased svn is currently using an eps
mode to draw north arrow decorations instead of the 'point' instruction
directly. the redundant eps north arrows should be removed before they
are used in an official release and the method is locked in for backwards
compatibility. Even if no one else cares about that, I do, so it is
probably up to me to fix & convert the better qgis north arrows to the
grass symbol format as needed.


anything non-gui-only which isn't strictly a bug fix only should be
identified in the changelog and have discussion about it. (e.g. style
changes to g.version stdout output, which user scripts might be [will be]
parsing; if we should backport new python functions like mapcalc_start()
which allow backgrounding jobs for python parallelization, or not)


thanks,
Hamish