Glynn,
(cc to grass5)
On Tue, Oct 09, 2001 at 06:25:03AM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> Generally numerous changes are to be expected, basically shared libs,
> new Makefile system, PROJ4 support (with datum transform) and the
> new vector lib (backward compatible), not to forget an improved directory
> layout and, build-in DBMS support. Enough for month, I think, but
> needed if we want that GRASS survives.OK.
The PROJ4 support and new vector library can be left mostly to the
people who are going to implement them.
yes - we need a sort of "work groups" to have a responsible person
for each part. I think it is impossible for one person to supervise
all changes.
The build system and directory layout really need to be open to
discussion by everyone.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.
Several of these actions will result in "whole file" changes, i.e.
where "cvs update" will retrieve a completely new version of the file
rather than patching an existing file. Consequently, it would be more
efficient for each file to undergo all of the above actions
simultaneously. Which requires that all of the stages are agreed in
advance.
We have to set up a list of checks to be followed before a module
may enter the grass51/ source tree. I guess we start to set up
the restructured libraries along with the new Makefile system, then
the modules.
Also, this might be a good time to look into the command startup
issues (G_parser() etc).> Question is, where to start... I fear that not all relevant
> people will come to Trento in November. How to deal with that?Use the mailing list. Plenty of open-source projects operate without
face-to-face meetings.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)
- 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)
- Andrea Aime and me are finishing the cats support for s.delaunay
(have been missing, which lead to broken polygons)
- more?
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?
I really think that we should start 5.1.0 instead of having two more
5.0.x versions... But I guess you agree.
--
Glynn Clements <glynn.clements@virgin.net>
Best regards
Markus Neteler