[GRASS-dev] grass-dev Digest, Vol 80, Issue 74

[Michael Barton]

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 at lists.osgeo.org<mailto:grass-dev-request at lists.osgeo.org>>
 wrote:

From: Helena Mitasova <hmitaso at ncsu.edu<mailto:hmitaso at 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 at lists.osgeo.org<mailto:grass-dev at 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 at gclements.plus.com<mailto:glynn at gclements.plus.com>>
_______________________________________________
grass-dev mailing list
grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20121031/5519cb9b/attachment-0001.html>