[GRASS-dev] Some ideas about future GRASS development

[Dylan Beaudette]

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


>
> 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.
>
>
> regards,
> Hamish
>
>
> 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
> appropriate.
>
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341