[GRASS5] Re: GRASS 5.1 startup

[Glynn Clements]

Markus Neteler wrote:

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

Actually, that was one of the motivations for implementing a uniform
coding style.

Whenever I've found code which appears to have been cloned (initially
src/display/devices, but there have been a couple of other case), one
factor which complicated comparison was that sometimes, one version of
the code (or maybe even both versions) had been re-formatted.

Another motivation is that, when someone is modifying files which use
different coding conventions (e.g. fixing a common type of warning,
changing a system-wide convention, etc), the indentation has to be
done manually.

With a common coding style, you can just configure your text editor to
perform automatic formatting; but this is only practical if the
formatting is the same for all files.

BTW, I have absolutely no preference as to *which* coding style is
adopted.

> > 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)

Can you clarify? I don't understand "NVIZ TOP button".

>  - 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)

Can this be done for r.proj? Are there any others?

> > 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?

By "5.0.1", I mean the result of just fixing the bugs which are found
in 5.0.0 once it actually gets released.

The changes involved for 5.1.0 will probably ensure that 5.1.1 follows
shortly after that. The development cycle invariably goes:

	1. make changes
	2. fix all of the bugs that you can find
	3. release to the public
	4. fix all of the bugs that the public managed to find (but
	   the developers didn't)
	5. GOTO 1

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