[GRASS-dev] Some ideas about future GRASS development

[Martin Landa]

Hi Jarek,

2010/4/28 Jarosław Jasiewicz <jarekj at amu.edu.pl>:
> That rather radical ideas I present here are rather for future, at least for
> GRASS 8, but I'd like present it now for long-term reflection.
>
> Probably all notice that for over two years there is big increase in add-on
> repository (including me). There are modules of different quality: from
> fully GRASS toolsets, to shell or python scripts, from  actively developed
> tools to abandoned, from all-purpose tools to very specialized etc. I also
> think that that activity will be grown due to substitute shell script by
> python
>
> Similar situation is in main GRASS branch: there are modules for all like
> conversion tools, interpolation methods, georeferencing etc, and very
> specialized modules for very limited group of users (like wild fire), there
> are also some modules out of date.
>
> I'm not enthusiastic about moving new modules into main branch. Almost every
> module has different coding style and it will lasting in future that GRASS
> would be difficult to maintain. On the other hand some people complains that
> some interesting modules are only available as add-ons (I assume for some
> reasons they cannot install it)
>
> So my suggestion is to rearrange future GRASS form two layers (main
> branch/add-on) into three layers architecture:
>
> 1) GRASS core layer: much limited limited than now, only GIS environment and
> basic, all-puropse tools, slow changes, great stability
> 2) GRASS toolset layer: oficcial GRASS thematic tools and toolsets (like
> terrain analysis, hydrological analysis, photo-interpretation, landscape
> analysis etc,) every toolset with its maintainer, rapid development, new
> ready to use tools after quality control may appear here, also some of
> current main branch tool shall be moved to that layer
> 3) GRASS community layer:  everything else like experimental, actively
> development new tools, that what do not pass quality control, simple
> scripts, etc....
>
> What benefits:
> for developers and contributors: much clear situation and better publication
> path.
> Toolset layer should be much more open for new tools than current GRASS main
> branch
>
> for users: faster access to new tools.
> There is no doubt that new tools are faster developed (less risk) than GRASS
> core
> Binaries with toolsets could be maintained as separate
> apt/urpmi/pacman/yum/exe etc packages, so it may appear in linux repository
> separetly form GRASS core.

I like your idea in general. I think there is enough time to discuss
new repository layout also for GRASS 7. I have created for this
purpose a wiki page [1].

Cheers, Martin

[1] http://grass.osgeo.org/wiki/GRASS_repository_layout_proposal

-- 
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa