[GRASS5] Re: GRASS 5.1 startup

[Markus Neteler]

Glynn,

(cc to grass5)

On Tue, Oct 09, 2001 at 06:25:03AM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > Generally numerous changes are to be expected, basically shared libs,
> > new Makefile system, PROJ4 support (with datum transform) and the
> > new vector lib (backward compatible), not to forget an improved directory
> > layout and, build-in DBMS support. Enough for month, I think, but
> > needed if we want that GRASS survives.
> 
> OK.
> 
> The PROJ4 support and new vector library can be left mostly to the
> people who are going to implement them.

yes - we need a sort of "work groups" to have a responsible person
for each part. I think it is impossible for one person to supervise
all changes.
 
> The build system and directory layout really need to be open to
> discussion by everyone.
> 
> I would like to suggest that we also start an official maintenance
> effort, including:
> 
> + Convert pre-ANSI code to use ANSI prototypes.
> + Implement a uniform coding style.
> + Remove unused code and variables.
> + Use "const" where appropriate.
> + Guard headers against repeated inclusion.
> + Move variable definitions from headers to source files.
> + Consistent use (or not) of "cmd" subdirectory.
> + Remove warnings (enable "-Wall" by default for gcc).
> + Consistent use of G_{warning,fatal_error,malloc,free} etc.

We should also check if certain code which is repeated everywhere
can be moved to the GRASS libraries. That's improving consistency
and (later) maintenance.
Eventually (!) here at ITC-irst we can use tools to identify such
code, they have a so-called "clone detector". But as GRASS is quite
big, it is no easy task to apply the "clone detector" to this code.
 
> Several of these actions will result in "whole file" changes, i.e. 
> where "cvs update" will retrieve a completely new version of the file
> rather than patching an existing file. Consequently, it would be more
> efficient for each file to undergo all of the above actions
> simultaneously. Which requires that all of the stages are agreed in
> advance.

We have to set up a list of checks to be followed before a module
may enter the grass51/ source tree. I guess we start to set up
the restructured libraries along with the new Makefile system, then
the modules.
 
> Also, this might be a good time to look into the command startup
> issues (G_parser() etc).
> 
> > Question is, where to start... I fear that not all relevant
> > people will come to Trento  in November. How to deal with that?
> 
> Use the mailing list. Plenty of open-source projects operate without
> face-to-face meetings.
> 
> BTW, what's left to do before 5.0 can be "released"?

see my other mail:

 - NVIZ TOP button needs a fix, NVIZ is really behaving strange here
   (Bob already spend a lot of time on that)
 - r.in.gdal: fix the currently hard_coded LL "projection" for
   GCPs (means: fix the wkt_to_grass()
 - Huidae is currently adding cats transfer to r.mapcalc for
   the two cases:
    new_mapname = oldmapname
    new_mapname = if(cond, old_mapname1, old_mapname2)
 - Andrea Aime and me are finishing the cats support for s.delaunay
   (have been missing, which lead to broken polygons)
 - more?

> Bear in mind that some problems only come to light once the software
> gets into the hands of people who don't use anything which is labelled
> "beta" or "pre-release". Actually, many people abide by the maxim of
> "never use a something-point-zero version of anything", so you might
> have to release 5.0.1 before you really start getting feedback. 
Do you think of 5.1.1 here?

I really think that we should start 5.1.0 instead of having two more
5.0.x versions... But I guess you agree.

> -- 
> Glynn Clements <glynn.clements at virgin.net>

Best regards

 Markus Neteler