[GRASS5] Towards a 5.1.0 experimantal release

[Glynn Clements]

Bernhard Reiter wrote:

> We would try to go for a real experimental release (5.1.0) tarball.
> Therefore we should move modules over by procedure to be defined
> and call a freeze on major features for 5.2.
> 
> For each module fully declared moved to 5.1 
> the development focus will change.
> Developments then have to take place in the 5.1 tree
> and focus on getting 5.1. ready for release.

This is the key issue. If the development focus is moved to 5.1, 5.0.x
needs to be frozen; the only subsequent changes to 5.0.x should be bug
fixes.

> If we all agree on the general plan 
> we could start making a list of modules that need to be moved
> and necessary cleanup steps that we might want to perform
> in the move.

Useful cleanup steps include:

 1. Uniform coding style.
 2. Use ANSI prototypes.
 3. Remove unused code and variables.
 4. Use "const" where appropriate.
 5. Guard headers against repeated inclusion.
 6. Move variable definitions from headers to source files.
 7. Consistent use (or not) of "cmd" subdirectory.
 8. Eliminate warnings (enable "-Wall" by default for gcc).
 9. Consistent use of G_{warning,fatal_error,malloc,free} etc.
10. Identify and remove cloned code.

Step 1 boils down to choosing a set of switches for the "indent"
program, then running indent on all source files.

Step 2 can be automated using "protoize".

Most of the others have to be done manually; some steps are so trivial
that they could be done by a non-programmer (e.g. step 5), while
others require non-trivial analysis of the code (e.g. step 4).

Step 4 has to be done bottom-up; i.e. start with core libraries
(libgis), then the higher-level libraries, then the programs.

Step 10 mostly boils down to creating one or more general utility
libraries to provide a home for shared code which doesn't belong in
any existing library.

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