[GRASS-dev] Some ideas about future GRASS development

[Michael Barton]

On May 11, 2010, at 8:43 AM, grass-dev-request at lists.osgeo.org wrote:

> Date: Mon, 10 May 2010 11:57:37 -0700
> From: Dylan Beaudette <debeaudette at ucdavis.edu>
> Subject: Re: [GRASS-dev] Some ideas about future GRASS development
> To: grass-dev at lists.osgeo.org
> Cc: Martin Landa <landa.martin at gmail.com>
> Message-ID: <201005101157.37149.dylan.beaudette at 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