[GRASS5] Towards a 5.1.0 experimental release

[Bernhard Reiter]

On Fri, May 16, 2003 at 08:27:32PM +0100, Glynn Clements wrote:
> 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.

Yes and we need a trigger script that alerts us 
if somebody still commits on such a module that is declared moved.

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

Note that we should only plan to do the work
we have developer resources committed.

Markus and Radim do all the work for GRASS 5.1
(with some people I think like you and Paul helping).
We can't make a list that in the end they have to do the work for.

I plan to help setting up the process and scripts driving it.
We need a list which everybody can see that shows what modules
still are scheduled for what step and which will be left behind,
because nobody commit the work to move them.

I'm also ready to tackle a few modules modules myself
if I get straight instructions.

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

Are you absolutely sure that this improves the situation
in all cases? Please suggest a set of switches that Radmin
and Markus agree with.

> Step 2 can be automated using "protoize".

You probabl mean:
http://gcc.gnu.org/onlinedocs/gcc/Running-Protoize.html

http://gcc.gnu.org/onlinedocs/gcc/Protoize-Caveats.html#Protoize%20Caveats
tells me that the result might need checking.

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

I don't think that we fully get 3. or 4. done for the move.
Same for 6 and possible 5 and 7.
Anyway, we might make a plan and record who did what.
It would be nice if we could identify the weaknesses by
a script that we could run each night and update it to the current
status.

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

A major task, unless we find somebody really putting time
into this, it won't happen for 5.1.

As always, we need developers helping with the job.
GRASS development is only as good as you all are!

	Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20030517/ad586fa4/attachment.bin