[GRASS5] GRASS 5.0.3 released

[Thierry Laronde]

On Sun, Nov 09, 2003 at 05:01:00PM +1300, Hamish wrote:
> 
> I would think that the GRASS 5.7 merge is the natural place to do such
> pruning, due to the mechanics of building 5.7 currently. We should just
> migrate things one by one to 5.7 (i.e. undo the'make mix' symlinks &
> replace with real code in the CVS), only migrating good code instead of
> a bulk copy of everything. 

In theory, this should work. In practice, my strong feeling, is that
this won't work, due to "user's pressure" ("Hey! all my scripts use this
command. Please retain it as a legacy one"), due to time pressure
(because this will take more and more time, naturally enough, the small
number of people contributing will take the shortest way putting roughly
the new API in the old programs whether or not they were shaped to
accept such a transplant) and due to the fact that people will focuse
on having the "old" programs work (will focuse on the vector engine, not
the structure) and will import the present structural flaws in the "new"
code.

Unfortunately, some new contributors (past CERL 4.1) have forgotten the
guidelines specified in the programmer's manual : portability,
modularity. Some "old" programs were undergoing some cleaning and a
rewrite, but this was not achieved. To take an image, some programs use
the "libc" (the API, accessing the internals via a defined interface)
while some others use directly the system calls. Trying to change the
internals without auditing first the code will introduce bugs that will
be a pain to track.

Note too that taking one at one the feature will prevent to have an
overview of the code. And this is precisely this overview that is
absolutely needed IMO.

> 
> Things like site support might continue to exist from 'make mix', but
> not actually pollute the formal 5.7 CVS. As 'make mix' is a pain, this
> encourages people to migrate or drop any outstanding functionality
> quickly, rather than letting it sit half-way for several years (as with
> current broken 4.3 code in 5.0's cvs).

The problem is that GRASS will import current broken 4.3 plus current
broken 5.3.

Reading the 4.1 manuals and browsing the 4.1 code (yes, to try to
understand where GRASS was going I have downloaded this code... and
I'm not quite sure I will not play with it a little...) there is a
structure underlying the code. The structure is the following (it will
help to consider GRASS as an "operating system" built on a "graphical
kernel"):

- There is the system code (the graphical kernel (internal structures),
the "libc" (the libes), the essentials programs: the shell, the 
essential user's and admin's programs [mainly developped at CERL], and 
including v.in.ascii and v.out.ascii but no "specialized" programs to
external formats ;

- Programs that interface the core with some external sources (this was
src.garden and include the graphical driver and the different import and
export modules);

- Userland programs or scripts, from large one (nviz) to small scripts
or programs aimed at a particular study (this was a large part of
src.contrib but there are programs in src that belong to this category)

These 3 major blocks should have (and had) separated trees, once the
system code is reliably able to propose an API with the compat libraries
for _one_ backward version (yes, I have seen that it has been worked on
in 5.7) so that userland programs can live a life of their own.

No external piece of code should go in the core system.

But the main task is to extract the core (the system) and to audit the
code which will lead to a new directory structure and a better view of
the changes needed and to several crucial choices to make. But since it
is an overview it can't be achieved by treating one file at a time.

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde at polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C