[GRASS5] Re: KerGIS

[Markus Neteler]

On Tue, Jan 27, 2004 at 01:15:29PM +0000, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > As I don't really work on the vector modules, any
> > > improvements to the display or raster modules automatically get fed into
> > > 5.7 so I don't feel at all guilty about 'neglecting' it.
> > 
> > This is actually not completely true. 
> > 
> > E.g. (recent changes)
> > 
> > 2004-01-24 02:53  <hidden>
> > 
> >         * XDRIVER/XDRIVER24/Graph_Set.c: Erase window at startup (prevents
> >         "transparent" window when starting without  selecting).
> > 
> > ... I had to merge. It's not clear to me why 5.7 is really *ignored*
> > by some developers.
> 
> Because it's a sufficiently radical departure from the existing code
> base that it's effectively a separate project, and not everyone has
> the time to work on two projects.
> 
> Maybe you should be asking whether it was really necessary fo 5.7 to
> have its own version of Graph_set.c, given that the differences amount
> to:
> 
> 1. A different cursor.
> 2. The default background being white instead of black.
> 
> Does this really justify forking that file (and also Serve_Xevent.c,
> solely for point 2)?

In my opinion there is no fork needed. I would appreciate to
see the 5.7 changes in 5.3.

> How many of the files which have been forked in 5.7 are really
> necessary? I'm not counting cases where, all other things being equal,
> the change would have been an improvement; because all other things
> aren't equal.

Several (most?) of the forks in libes/gis/, XDRIVER etc. could be
merged from 5.7 into 5.3. But this requires that someone else than
me checks it. 
E.g: If 5.3 users prefer the black X-monitor over the white X-monitor 
     in 5.7, we cannot merge. The same applies to the improved cursor
     in 5.7. 

We'll certainly not replace the improvements in 5.7 with old code 
from 5.3.

> Minimising divergence between the two code bases ought to carry *some*
> weight (I'm not arguing how much weight, only that it should be
> non-zero), and changes should only be made if they provide "enough"
> benefit.

Minimising divergence requires that 5.3 developers look at 5.7.
Unless they aren't willing to do that, the minimization of divergences 
will have to wait, unfortunately.

Markus