[GRASS-dev] Some ideas about future GRASS development

Jarosław Jasiewicz jarekj at amu.edu.pl
Mon May 10 07:49:58 EDT 2010


Hi Martin, Hamish, all...
> Hi,
>
> 2010/5/10 Hamish <hamish_b at yahoo.com>:
>   
>>    * One of our best selling points vs. the competition is that you don't have to buy expensive addon toolboxes to have it do what you want to do.
>>    * It makes it a lot harder for new users to get started with what they want to do. Even when done well it's a brittle system dependent on 100% uptime servers etc. which in practice do not exist.
>>     
Now new user is frequently referred to add-ons where are modules of 
different quality. And new users are really lost. Now everyone can add 
something to add-on nobody control its quality or sense. Toolboxes (or 
any similar) will give quality control on new modules. Everything in 
toolboxes is good quality, but may not be useful for everyone.
>
> advanced Tools Manager could help with that, see the minimalistic approach [1].
>   
Even not very advanced.
>>    * Non-"core" modules will be neglected by the core devs and die from bit rot. (outside of grep's reach)
>>    * Those "non-core" modules have personally led me into all new ideas and directions outside of my normal field of study, which has rather positively affected the direction of my career and let me solve problems in novel ways for my peers that only cross-discipline tools/perspective could introduce us to.
>>     
>
>   
I think both core and toolboxes could be still "GRASS-CORE" and will be 
maintained together (if require), in the same manner.
> I am not afraid of that. Core should be minimalistic, the most modules
>   
   * 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.
>>    * Rather than focus development I fear it will dilute it. Divided we fall..
>>     
This is not idea of divide! This is idea of better integration 
contributors and developers. I't is good you point out dangerous of such 
approach but I is idea of increase the number of developers with 
different competitions.
>>    * Big change is big work which could more productively be funneled into more critical pursuits. (I am not against needed change, but very against change-for-change's-sake.)
>>     
So you think we do not need new functionalities in GRASS?

>
> The main question is which modules should to moved from grass-addons
> to trunk. Who will decide, PSC? As reference I can mention modules
> from GIPE which has been moved to trunk few months ago.
>
> Basically, I like the idea of minimalistic repo for libs and core
> modules which will be maintained carefully to be very stable. And
> grass-tools with solid and *maintained* modules. The rest in
> grass-addons. Currently grass-addons contains a mess, you can find
> very good modules but also unusable rubbish. The user is lost.
>   
it is exactly my idea, but I think it is problem of feature, I think 
problem is, but I didn't say that my proposition will really help. In 
general the aim is to join more people into GRASS developing, not divide 
GRASS into parts. In some parts GRASS shall develop slow and concentrate 
on "critical pursuits" in some parts (toolboxes) it could develop faster 
- nothing more...
 
best
Jarek


More information about the grass-dev mailing list