[GRASS-dev] Some ideas about future GRASS development

[Jarosław Jasiewicz]

Martin Landa pisze:
> Hi,
>
> 2010/5/10 Hamish <hamish_b at yahoo.com>:
>   
>>> 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)
>>     
>
> OK, anyway from my point of view space-size is not the reason of this
> changes. The main reason for me is to clean up the GRASS modules and
> to split them to 'core', 'tools' (well maintained) and 'addons' for
> rest.
>
>   
>> devel mode for new (mostly quick script) 
chmm.. I quick look into add-on repository and most new modules from 
2009/10 are rather C-modules than quick scripts....
>> 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
>>     
>
> well, the main tree would be nice too keep minimalistic. Then is less
> work to maintain it.
>
> Martin
>
> [...]
>
>   
>> 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.
>>     
>
> wxGUI menu could be easily by g.extension when installing new
> module(s). Of course the proposed repo layout requires solid
> g.extension module.
>
>