I agree with Helena. It is very good when working with many projects and students–and demo-ing GRASS to other organizations–to have a very complete tool set. On the other hand, it would help to have some established guidelines about what is best moved to trunk and what things might be best moved out.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
On Oct 30, 2012, at 9:47 PM, <grass-dev-request@lists.osgeo.org>
wrote:
From: Helena Mitasova <hmitaso@ncsu.edu>
Subject: Re: [GRASS-dev] r.modis in GRASS 7 trunk
Date: October 30, 2012 1:55:36 PM MST
To: GRASS developers list <grass-dev@lists.osgeo.org>
I agree with Glynn and Ben,
when working with students on 50+ different projects it is really great to have everything
in one package and not to worry about which additional tool to install and whether it will work with the latest release.
We used to have the code split into core, alpha and several other groups and it was pain to maintain,
I think it works much better now and the toolbox concept should be implemented at the GUI level.
Maybe PSC should have some mechanism to decide on which add-ons to move to trunk based on a defined set of criteria.Helena
On Oct 30, 2012, at 12:53 PM, Glynn Clements wrote:
Martin Landa wrote:
as a regular user of MODIS, I would like to call other MODIS users to
express interest to include r.modis into GRASS 7 SVN.we cannot extend number of modules in trunk forever. Probably some
modules should be reviewed and moved to addons.Why?
Keeping modules in trunk ensures that any breakage resulting from
changes to APIs or to the build system will be noticed. Also, the
module will be included in the linkage database created by
tools/sql.sh, and in any recursive grep of the source tree.Personally, I’d rather see most “normal” add-ons moved into trunk.
OTOH, v.in.dwg should be moved to add-ons unless LibreDWG support is
expected in the foreseeable future.–
Glynn Clements <glynn@gclements.plus.com>
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev