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.
I'm not sure that a module-by-module transition is really viable.
It would be better to just declare that all development should move to
5.1, and that anyone wanting to update a module which hasn't yet been
transitioned to 5.1 should start by transitioning the module to 5.1
then working on that.
> > 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'm happy to move from 5.0 to 5.1 if an authoritative decision is made
to do so, but I don't intend to do active development on two
substantially different versions at once, and any move to 5.1 would
effectively be permanent (I would be willing to do bug-fixes for
5.0.x, but not anything more substantial).
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.
I could do a lot of the "bulk" work, i.e. the situations where it's
clear what need to be done (particuarly steps 1, 2 and 5, and to a
lesser extent steps 3, 4, 6, 7 and 9).
> 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?
Yes. The current situation means that, if I am editing a bunch of
files which are spread across various modules, I have to either:
a) change XEmacs' formatting rules for each file that I edit,
b) manually adjust the formatting of individual lines, or
c) disable auto-formatting altogether.
Please suggest a set of switches that Radmin
and Markus agree with.
Well, the one thing that's been holding this up is reaching agreement
as to exactly what the coding style should be. IIRC, Markus did once
suggest a set of switches, and nobody commented.
Assuming that Radim has used the same style for all of the existing
work on 5.1, maybe we should just figure out which indent switches
produce that style and use those?
> 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.
AFAICT, all of the likely failures will result in errors.
> 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.
The most important one to do at the same time as the move is 1, as it
often changes most of the source file, resulting in a large diff,
which not only wastes bandwidth when doing "cvs update", it also makes
a mess of any "cvs diff" operations which span the reformatting.
The rest can be done as time allows.
However, use of "const" in core libraries should be done sooner rather
than later. Lack of "const" is almost a bug IMHO; worse, it "infests"
all callers, as they have to declare their own arguments as mutable,
creating the same problem for their callers etc.
> 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,
It shouldn't be. At a minimum, you could just add the cloned function
to libgis. Even if it's moved to some other library, the corresponding
Makefile changes are trivial.
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!
Just revoke everyone's commit access for the 5.0 tree; people will
start working on 5.1 soon enough 
--
Glynn Clements <glynn.clements@virgin.net>
