[GRASS5] Towards a 5.1.0 experimental release

[Markus Neteler]

On Sat, May 17, 2003 at 12:13:50AM +0200, Bernhard Reiter wrote:
> 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.

Right - as they won't do it all alone for several reasons:
- our institute allows us only to dedicate a certain percentage of our
  work time to GRASS development (yes, we have lot's of other projects
  to do)
- I am more a non-programmer than programmer
- it's much to much for 1.x people

> I plan to help setting up the process and scripts driving it.

That's most welcome.

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

Due to my experience the GRASS developers tend to concentrate
to work on things they need, which is reasonable and should be
kept in mind when defining steps.

A starting point is to work on the code which is currently linked
into 5.1. We have chosen modules which seemed to be important to
cover base GIS functionality. Those missing such as 'r.support'
require significant overhaul, e.g. to have full CMD line support.

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

We should definitly start to clean up and improve libgis.
Also the documentation should be moved into the code (from
the ProgMan) in doxygen style (see 5.1 vector lib how to
do that). It's impossible to maintain this separated from the
code.

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

I have already suggested this month ago and proposed to use
the indent rule used by the Apache people (see grass5 archive,
can't find the ref now).
If you look at lib/image3/ you see an absolute nightmare of
code layout.

Roger Bivand pointed out that files should be even split in
libgis to make R/GRASS interface programming easier.

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

Why not? At least 3 should be done (enjoy lib/ogsf/ for unused variables).

> Same for 6 and possible 5 and 7.
> Anyway, we might make a plan and record who did what.

Step 8 is already done.

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

Yes. If available, I could add it to the grass web site.

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

At least functions present in the libs should be used and local
versions (often identical) deleted (see the imagery modules, I feel
that the imagery lib was developed after several modules had been written).

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

You are most welcome to participate in steps 1..10 :-)

I think Radim and me are at the absolute maximum what we can provide
for GRASS development. Without getting more programmers on board it
will take a lot of time.

Dear professors, maybe you can invite motivated students (computer
science etc) to work on some tasks?

Markus