Perhaps it would be a good idea to put all of the suggestions on a wiki page and include a draft list of core modules, to see how easy it will be to agree on them. For example I would like to keep the simwe modules outside the core but readily available in binaries - we use it a lot but it is very specialized. There are several add ons that would be great to have either in core or more readily available in binaries within toolboxes.
Helena P.S. It looks like the windows daily snapshots for grass70 http://josef.fsv.cvut.cz/wingrass/grass70/ is down? On Jan 12, 2011, at 6:53 AM, Martin Landa wrote: > Hi, > > 2011/1/12 Yann Chemin <yann.che...@gmail.com>: >> (Thx, did not read that one yet, so did now) >> >> I would tend to agree with Jarek too. >> >> The use of Module keywords should facilitate the three layers >> mentioned, and maybe special keywords like "core", "toolbox", >> "experimental" could permit three levels of compilation of GRASS GIS >> (Basic, Advanced, Dev). > > user should have possibility to easily install > > 1) whole toolboxes, eg. `g.toolbox toolbox=hydrology` would install > all modules related to hydrology > > 2) modules, eg. g.extension extension=r.stream` would install only > given module (or it could be integrated in g.toolbox) > > Of course we could distribute packages with common toolboxes like now > we are doing. I think it would make development more transparent. The > core would contain only libs and small subset of modules with high > stability (grass/trunk), toolboxes maintained and stable modules > (grass-tools/trunk) and the reset could be in grass-addons. > > Martin > > -- > Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
