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

[Glynn Clements]

Hamish wrote:

> > Those functions aren't the problem. The problem with v.extract is that
> > it's calling them before it calls G_gisinit(), which is supposed to be
> > called before any other GRASS function.
> > 
> > [Apart from anything else, G_gisinit() sets the program name, which is
> > used by G_fatal_error(), so anything which might cause G_fatal_error()
> > to be called (i.e. almost everything) cannot safely be called before
> > G_[no_]gisinit().]
> > 
> > I have no idea whether or not this actually causes problems at
> > present; I'm just pointing out that it's a bug regardless of whether
> > or not you happen to "get away with it".
> 
> Added some comments to lib/gis/parser.c about this for more visibility.
> (non-doxygenized header)
> 
> I notice g.region has fallen afoul of this rule in the last 2 weeks.

I noticed that g.region didn't comply (use of llinfo() and
G_{lat,lon}_format_string()) when I updated it to handle GRASS_REGION
and WIND_OVERRIDE, but I didn't realise that this was recent.

> If the change is to be made so stuff happening before G_parser() will
> trigger a fatal error, can this wait until after 6.1.0 is released?

Certainly.

In any case, the change would initially need to be done in such a way
that it could be disabled easily, in case it turns out that a
substantial proportion of modules don't comply (especially critical
ones such as g.region).

Intentionally triggering bugs as a mechanism to get them fixed only
works if it doesn't result in everyone just reverting to the previous
version.

> 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'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 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.

-- 
Glynn Clements <glynn at gclements.plus.com>