[GRASS-dev] GRASS 7 timeline

[Glynn Clements]

Markus Neteler wrote:

> > my wishes for the GRASS 7.0.0 release
> > * native MS windows fully stable and equal
> >   - worthy of a major point release, if simply for the PR value
> 
> I hope to see major MS-Windows support already in 6.3.0!
> At least we were telling so for some months... and not too
> much seems to be missing.

There's a difference between "support" and "fully ... equal".

Monitors don't work, and several programs won't work without them.

OTOH, I've just modified v.digit not to require the form library
(which doesn't work on native Windows), so hopefully that should work
now (or, at least, soon; it needs testing first).

> > 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)
> 
> In order to maintain the history, we have to move the entire CVS to
> SVN first. Means, that 6.3.0 could come from SVN if the winGRASS port
> completion takes more months (hopefully not).

That depends upon how "completion" is defined. Most of the critical
functionality is available, assuming that you can accept gis.m as a
substitute for using d.* with monitors, but there are plenty of dark
corners with some rather hard-to-port code (mostly in the imagery
directory).

> > > 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 that it is our policy to not discontinue modules in a release
> cycle. So i.ortho.photo should remain in 6.x.

Right; but any significant changes to the graphics architecture are
essentially stalled in the meantime.

> Brad has proposed a series of improvements to i.ortho.photo and AFAIK
> already implemented most of them. Why don't we take a look at these?

The i.ortho.photo issue is that it requires a monitor. Changing that
involves a significant re-write (i.e. separate the functionality from
the interface, and re-implement the interface in Tcl/Tk or wxPython). 

AIUI, Brad was planning on doing this to i.class first, as it needs
essentially the same treatment, and i.class is a signficantly simpler
program than i.ortho.photo. The i.class changes haven't happened yet,
so having the i.ortho.photo re-write completed is still a way off.

> > 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.
> 
> This list should go into the Wiki, here it's quickly getting lost.

You can get the list of "problem" modules from the SQL database
generated by tools/sql.sh:
	
grass=> SELECT DISTINCT program FROM prog_imp WHERE symbol LIKE 'R\\_get\\_location%' ;
       program       
---------------------
 bin/d.barscale
 bin/d.extract
 bin/d.geodesic
 bin/d.legend
 bin/d.measure
 bin/d.nviz
 bin/d.path
 bin/d.profile
 bin/d.rast.edit
 bin/d.rhumbline
 bin/d.text.freetype
 bin/d.text.new
 bin/d.what.rast
 bin/d.what.vect
 bin/d.where
 bin/d.zoom
 bin/i.class
 bin/i.points
 bin/i.vpoints
 bin/r.digit
 bin/r.le.setup
 bin/r.profile
 etc/i.ask
 etc/photo.2image
 etc/photo.2target
(25 rows)

Some of these only make minor use of the mouse (e.g. "d.barscale -m"),
in which case you only lose the mouse-specific functionality without a
monitor. Others (i.*, d.rast.edit, r.digit) need a major re-write.

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