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

[Michael Barton]

We probably should go ahead toward 6.2--meaning a feature freeze and living
with some work arounds.

I've just finished a gis.m TclTk replacement for d.profile and can get it
into the cvs in the next few days. I just need to make a couple of button
icons. I didn't think I'd get it done, but I hope you can let me get add it
to the cvs now that it's done.

The only other thing I can think of that really needs to be fixed (can be
dealt with as a bug fix after the freeze) is the region problem. Maybe it's
already fixed by Cedric, but I haven't had a chance to check it yet.

Doing replacements for i.points and v.digit will take more work, possibly
reprogramming in C (pretty sure about v.digit, still might be able to do all
of an i.points replacement in TclTk, but I'm not yet sure). As much as I'd
like to have a complete x11 free GUI for 6.2, I don't think we can get there
yet--unless some rapidfire development can be done by someone else. But
we've come a long way and have a very nice product.

One thing that should be done is to change the current i.points (in the
menu?) so that it doesn't automatically launch an xmonitor. The reason is
that the monitor cannot be resized after i.points is started and it always
launches too small. Better to have it done manually.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam at yahoo.com>
> Date: Fri, 19 May 2006 16:15:42 +1200
> To: Glynn Clements <glynn at gclements.plus.com>
> Cc: <grass-dev at grass.itc.it>
> Subject: Re: [bug #3117] [GRASS-dev] povray and grass   [-> 6.1.0 freeze &
> release?]
> 
>>> 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&d
> isplay=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
> 
>