Hi Jarek, 2010/4/28 Jarosław Jasiewicz <[email protected]>: > 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
