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 > [email protected] > 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
