[GRASS-dev] Some ideas about future GRASS development
debeaudette at ucdavis.edu
Mon May 10 14:57:37 EDT 2010
On Monday 10 May 2010, Hamish wrote:
> > > * 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.
> > 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
> (mean size of modules in bin/ for me is 60k .... +50 modules *60k = 3mb)
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.
> mostly I just want to be convinced that the existing model is badly
> broken before we try and replace it by something which may or may not
> be the same or better.
> ps- wrt GIPE, any thoughts on renaming r.vi to the less jargony r.vegindex,
> and should i.sunhours be r.sunhours, etc? Still some QA work to do on all
> newly introduced modules.. (nothing really badly wrong about them, just
> that some of their peer-modules have 20 years of field testing behind
> them, so our standards are very high and consistent quality takes more
> effort than we might think)
> on the subject of fighting jargon (and moving totally off-topic :), I had
> spent some hours going through the GUI menus removing jargon which is
> natural to us long-time users but totally meaningless to new users. (e.g.
> how should they know that "GDAL" will open their file when it is a ".tif"
> not a ".gdal") but all that got clobbered. I am unsure of the automated
> wx menu sync tool, is it and a guide as to how we should work with the
> menus documented anywhere? anyway I feel that menu items should be a
> little more "easy" and module descriptions be more precise/accurate as to
> function. using the text same for both while easier isn't always very
> grass-dev mailing list
> grass-dev at lists.osgeo.org
Soil Resource Laboratory
University of California at Davis
More information about the grass-dev