[GRASS-dev] GRASS 7 timeline

[Markus Neteler]

[merging in Glynn's answer at bottom]

On Wed, Mar 14, 2007 at 08:02:18PM +1300, Hamish wrote:
> Glynn Clements wrote:
> > Is there an expected timeline for 7.x?
> 
> 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)

We can seriously think about it once the migration to SVN is
done.
 
> 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.

> * wxPython fully implemented for all GUIs
>   - no or minimal Tcl, for a consistent user experience
>     keep Tcl as non-default, optional "oldgui" ??? (answer that later)
> * no more interactive d.*, xterm GUIs, etc
> * 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?

New raster format definitely deserved a major version number.

> the raster format changes could mean a time of dual branch development
> like we had for Radim+Markus working on 5.1/5.7/6 and most everyone else
> working on 5.0/5.4. Markus may have some stern words about that. ;)

A period of dual branch development won't be avoidable. Maybe
SVN is helpful in this regard. 
 
> > 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?

I don't see a reason why not having a 6.4 stable release.

> (FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a 
> nice milestone once winGrass is usable.

Right. Basically the winGRASS port completion (say, that relevant
modules and startup are working) is holding 6.3.0 now.

> 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).

> [*] r.li could be safely backported to 6.2?

I highly recommend to do testing of r.li.* first. I have fixed a
few tons of issues and added some test script to
raster/r.li/TODO
based on spearfish. I get all sort of suspect results (see there)!

> 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.
> ??

at least 'd.m' seems to be unmaintained and probably almost unused.


> 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.
> 
> 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.
> 
>  
> > 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.
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?

> 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.
 
> > 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.

Agreed. Just start it. But call it GRASS 7. Following gravity law,
folks will migrate over (as it did for the 5.x -> 5.7 -> 6.0 path).

> 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. And GRASS 7 devel won't hurt those who still want to use
> GRASS 6. So no worries.

Other example: We are updating our book to GRASS 6.3. So it would only
partially work with GRASS 7 once it is there. But that will take time.
There will be necessarily overlap between 6.x and 7.x development.

#######

On Wed, Mar 14, 2007 at 12:40:33PM +0000, Glynn Clements wrote:
> 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 may block progress in the current release but not in a higher
version number. So, i.ortho.photo should not be dropped from 6.x
but could be for 7.x.

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

concerning i.ortho.photo:
- besides "important" there can be also a knowledge gap, i.e. that
  nobody of the *current* team is *able* to implement it again
- Brad proposed a series of improvements:
  http://grass.itc.it/pipermail/grass-dev/2006-December/028073.html
  I suggest to revisit this.

Markus