[GRASS-dev] 6.4.4 planning

[Hamish]

on the grass-user ML Markus N wrote:
> (and it is time to get 6.4.4 out...)


fwiw,

I've gone through the two branches with kdiff3 and selectively backported
many of the differences between the branches. There are a number of
experiments and minor cosmetic changes which I didn't backport. One big
remaining hope I had for 6.4.4 was to backport the parallelization work
in the imagery scripts, e.g. i.landsat.rgb. I think they are pretty good
but I haven't tried them on WinGrass to learn how well MSys deals with
backgrounding jobs with "&". I had planned to merge scripts/ first, to
give them the maximum amount of testing in the stable branch, but it turned
out to be too big a job for the small windows of time I could give to it. But now I am mostly waiting on testing them in 6.5 nightly WinGrass.


"Important bugs concerning the next release"
  https://trac.osgeo.org/grass/report/13

The other two important tasks for 6.4.4 in my mind are to get python addon
scripts working with 6.4's g.extension.py, both for Linux and WinGrass (#1768,
just committed an experimental change to 6.5svn a few days ago; e.g. for
r.threshold), and secondly to get the Cairo driver working on WinGrass (#943).

The Cairo driver seems to need some G_spawn() pipe handling/closing in d.mon,
using SF_BACKGROUND and other popen flags which I just stumble around in the
dark with & need some assistance.


It's our busy field season right now and I'm just about to head back
out to sea, so I won't be here to work on things for the next few weeks
(... and then the holidays come).


Are there critical bugs fixed in 6.4.4svn since 6.4.3 that demand we ship
a fix for ASAP? If not, I'd like to put some energy into the above issues
first. If there is some critical need to release now, I don't mind putting
these other things off for a 6.4.5, but especially the 'running custom
python scripts' in 6.4 WinGrass seems like an important thing to have
working out of the box for end users.


thanks,
Hamish