[bug #3117] [GRASS-dev] povray and grass [-> 6.1.0 freeze & release?]

[Hamish]

> > On the subject of 6.1.0, are there objections to declaring the
> > feature freeze in force /as of now/ and plan for a release date of 1
> > June? We need to stop breaking and refactoring things for a little
> > while. AFAICT things have gotten *less* stable since the start of
> > this month, the original time the freeze was suggested to begin. And
> > 6.1.0 is overdue.
> > 
> > I would like to freeze everything but gis.m and the r.3D modules- I
> > don't want to kill the development momentum they currently enjoy.
> > Gis.m is important to have working well,
> 
> The main issue there is that gis.m development may highlight further
> architectural problems within GRASS. IOW, you might find that making
> specific features work (or fixing specific bugs) requires potentially
> destabilising changes to core GRASS code.

I am sure further development will highlight other deficiencies, but we
live in an imperfect world and have to draw a line somewhere.


As I see it we have three choices:

* Feature freeze now. This doesn't mean stop work on gis.m, e.g.
disallow new buttons, but no new structural changes. For the next few
months we would have to be content with working around architectural
unfortunates. This means enthusiasm-killing slowdown & repetition of
work later on, but by then we should have a very clear idea of the
problem and a well thought out solution which could be swiftly
implemented. :-)

* Accept some level of instability in the 6.2-rc cycle, leading to a
more buggy 6.2.0. In this case perhaps do a monthly tag of 6.1.1, 6.1.2,
6.1.3 for three months, then declare a harder freeze. :-/

* Endless development, release 6.2 in 2009. :-(


I don't think declaring a freeze which still allows "structural changes
to libgis for gis.m only" is useful.

I am keen for a freeze as I was really impressed by how successful the
6.0 one was. As 6.1.0 will be a developement preview release, gis.m
doesn't have to be perfect for it -- I agree with the suggestions to
create a gisenv setting to allow d.m to be the primary GUI to
accommodate conservative users. That way 6.1.0 could in practice be used
as a stable version for "production use" (whatever that means).


> > I'm not sure if this is fixed yet, but it would be very nice if
> > 5.4.1 could ignore the extra 3D lines in a GRASS 6 mapset's WIND
> > file gracefully. The 5.4 release branch probably needs some merging
> > from grass5 HEAD; I think 6.0.x branch has been kept pretty much up
> > to date.
> 
> I suspect that we've reached the point where maintaining 5.x is
> becoming impractical.

I agree we are past the point of developing 5.x. Certainly we can
and should backport small but important fixes to the 5.4.x branch.
As long as 5.4.1 contains the 3D WIND parms fix to make it forward-
compatible with GRASS 6 mapsets, I don't mind it being the last planned
version. Installing fftw 2.x and tcl 8.3, is a small cost if you want to
use an older version of GRASS, no need to update for them, 64bitness.

> I haven't looked at it in months; I haven't even done "cvs update"
> since early February. Anything beyond trivial bug-fixes would require
> climbing the learning curve again.

Others have. What important bug fixes haven't been backported?

https://intevation.de/rt/webrt?q_status=resolved&q_queue=grass&q_area=grass6&display=Queue

possibles: bug #3100, 4045, 4145

The only other one that comes to mind is the small region raster lib fix
of a couple of months ago, but I wasn't involved in that so not sure.




Hamish