[GRASS-dev] GRASS 7 timeline [was: d.menu, d.ask]

[Glynn Clements]

Hamish wrote:

> That is entirely up to the fine folks on this list; I would guess that
> when the time comes, we know & we do it. Maybe then is now? I would not
> object to it happening as soon as the SVN server is up and running. (no
> technical reason for that, just a nice time for it to happen)
> 
> my wishes for the GRASS 7.0.0 release
> * native MS windows fully stable and equal

For the native Windows version to be fully "equal", monitors need to
be made to work. Even if we ditched all of the programs which require
a monitor (e.g. i.ortho.photo), so long as d.* commands can be used
with a monitor, the absence of monitors will make Windows less than
equal.

> * no more interactive d.*, xterm GUIs, etc

By "interactive d.*", are you talking solely of the use of the mouse,
or about the ability to use them with monitors rather than within
gis.m?

In any case, saying "no more interactive d.*" for 7.0.0 stable and (in
your previous message) means that's going to be a long way off. And a
lot of the changes to the graphics architecture cannot even *start*
until the R_get_location_with_* cruft is ditched. Once that does
happen, the graphics architecture is going to become highly unstable.

IOW, a new graphics architecture remains almost as far away now as it
does when it was first discussed a few years back.

> * centralized $MAPSET/raster/$MAPNAME/element
> * more?
>   - would a new raster format mean a new major point? or ok as long
>     as lib fns were backwards compatible with the old format? too much
>     to ask to support both? or r.convert module, like G6's v.convert?

Your wish list is too long. Given the glacial pace of GRASS
development, a version with all of these features won't be ready
within the next decade.

> > If so, does that signify a point at which fundamental changes to the
> > graphics architecture can commence?
> 
> I guess we could restate the question as do we want/need a GRASS 6.4
> stable release, or should we continue in devel mode all the way to 7.0?
> 
> (FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a 
> nice milestone once winGrass is usable. If no 6.4 is planned, then there
> is no need for a new SVN branch for 7.0 devel, we just continue with
> 6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and
> cull away)
> 
> [*] r.li could be safely backported to 6.2? Tcl GUI updates less so but
> we shouldn't abandon them. I guess they will be the day-to-day GUI
> during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing.
> ??
> 
> The 6.x problem is not with fundamental changes to the underlying
> architecture, that is wide open during a development minor version, and
> AFAIAC go for it. The issue is changing the user interface to the
> extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no
> longer works with "GRASS 6". So we are free to "get our ducks in a row"
> now, and we should do that, we just have to make an effort to minimize
> user pain as we go.

You can't make *fundamental* architectural changes without some of
that "leaking" into user-visible changes.

> When it is apparent that we have reached the point where the effort to
> maintain backwards compatibility is a big time+energy sink, we trigger
> the start of GRASS 7 development, without regret.

The effor to maintain backwards compatibility has *always* been a big
time and energy sink.

With regard to the graphics architecture, the need to support
standalone display drivers is by far the biggest obstacle. If the
raster/display libraries were simply rendering libraries (like e.g. 
GD), any changes or enhancements would only require 1/10th as much
effort.

> > If not, i.e. if i.ortho.photo *has* to continue to work until such
> > time that someone sees fit to write an alternative (if that ever
> > happens), then the graphics architecture will forever be limited to a
> > Tek4105 emulation, and I may as well give up now.
> 
> I think we can, today, clearly make a list of things that will not be in
> GRASS 7. Firstly a list of lib fn families, and secondly a list of
> modules. Presumably replacements GUIs for missing modules will come
> on-line in proportion to the demand for module's functionality.

However, the billion-dollar question is this: if a module *doesn't*
get re-implemented in a reasonable time-frame, can it be dropped, or
does it continue to block progress indefinitely?

It seems that certain modules are considered too important to drop,
but not important enough for anyone to actually re-implement them.

[Yes, I'm thinking primarily about i.ortho.photo; the other stuff I
could do myself if necessary.]

> > IMHO, I don't think that we can wait forever for decent graphics. The
> > biggest danger is that the "you can't remove that because someone
> > still uses it" problem will end up solving itself when no-one actually
> > uses GRASS any more. I'd prefer people to set achievable goals than to
> > insist on having everything and ending up with nothing.
> 
> We just have to call it GRASS 7. As that is just a number it is simple to
> change. No need to artificially slow down development to keep 6.x alive.
> e.g. People with need for GRASS 5.4 can still use that if they want,
> without loss of functionality, new devel switching to GRASS 6 hasn't
> changed that.

Hmm. Anyone using 5.4 can't share vector data with anyone using 6.x. 
Also, any bug fixes to 6.x won't get back-ported to 5.4.

The same will be true once work starts on 7.x.

> And GRASS 7 devel won't hurt those who still want to use
> GRASS 6. So no worries.

That's fine so long as there aren't any major problems with 6.x. Once
you start making changes which affect a lot of code, back-porting
fixes ceases to become viable.

-- 
Glynn Clements <glynn at gclements.plus.com>