[GRASS-dev] Some ideas about future GRASS development

[Hamish]

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)



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. :)


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.