On May 11, 2010, at 8:43 AM, grass-dev-request@lists.osgeo.org wrote:
Date: Mon, 10 May 2010 11:57:37 -0700
From: Dylan Beaudette <debeaudette@ucdavis.edu>
Subject: Re: [GRASS-dev] Some ideas about future GRASS development
To: grass-dev@lists.osgeo.org
Cc: Martin Landa <landa.martin@gmail.com>
Message-ID: <201005101157.37149.dylan.beaudette@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"On Monday 10 May 2010, Hamish wrote:
Hamish:
* Our download size is only about 25ish megs.
that's tiny. Docs are bigger than code. Windows deps "aren't
our fault" and switching to a different distribution model
won't help that much at all.Martin:
well, then we can build separate packages based on the
tools included, at least 'grass-core', grass-full`.my point is that splitting it up doesn't gain us much space-wise. An extra
50 modules might only cost another 6mb on top of the core distro.For WinGrass 80mb+6mb vs 86mb. might as well just ship the full 86mb
version in the first place and save everyone the extra 1000% installation
trouble.(mean size of modules in bin/ for me is 60k .... +50 modules *60k = 3mb)
Hi,
I can see the logic in splitting grass up into chunks to facilitate the
development of new modules without exposing the core modules to irresponsible
tinkering. I also like the way in which R is setup along these lines.
However, I don't think that there are enough willing individuals (as compared
to what is required to run something like CRAN) nor massive inflow of new
modules (as compared to R development) to warrant such a drastic change.
Furthermore, we don't even have the infrastructure to support such a system.
Maybe in the future, but not right now-- all efforts should be placed on
making GRASS 65 rock solid and GRASS 7 closer to a reality.as far as addon quality variability goes, I don't see that changing much
regardless of the system. As it is a technical decision about what is
up-to-quality so I prefer to leave the PSC out of it. FWIW my general
devel mode for new (mostly quick script) modules is to develop them in
addons, and once they are of what I consider to be release quality if they
have general appeal move them into main. Others which are very useful to
me but a bit less general use or only 95% happy with I've left in addons
to avoid cluttering the main tree. I figure anything from addons useful
enough will generally generate enough feedback and core-dev interest to
naturally migrate to the main tree. If it has a champion from the core
dev team with write access to the core development tree who cares enough
to move it across, then it has a long-term maintainer and is not much
extra load to the other core devs.I'll second that- there is a wide range of stuff in the addons branch. I have
seen some very good stuff in addons that I would like to see in the GRASS
proper. I don't know how it would happen, but at some point we should do some
house cleaning in the addons repository. Perhaps we can get a couple of
interested devs + users to go through and rate each of the modules-- then
those scoring above a certain threshold would be moved into GRASS proper.Recently sumitting a package to CRAN makes me realize just how much back-end
work, planning, and volunteer work goes into that system.Good discussion,
Dylan
My main concern about this idea is the 3-part division. I agree that a more systematic and more transparent process to move modules from addons to standard distribution would be welcome, and maybe is the first thing we need to consider re this discussion.
However, trying to decide what are core modules vs. additional modules for an extended version is more problematic. What are core for some will be extra for others. There is not really a space problem, so I'd prefer to stick with the easier to decide on core/addon 2-part division. This parallels the equally successful R/CRAN model. As noted, we need to continue to improve the ability of binary distributions of GRASS--on all platforms--to find and install addons from the repository. We have a good start on that (though I've yet to have this work, it almost does). I think we're on the right track software wise, but need to do a better job of administering the submission, incubation, and inclusion processes.
I have a couple things to add on GUI, but will save those for a different thread.
Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton