Hi,<div>I'm with Helena, Glynn and Ben,</div><div>I think that having many module in one package is better for users that do not have to take care of anything else.</div><div>If I have GRASS installed, I can find anything there (without need of searching for additional modules that are not found in the manuals!).</div>
<div><br></div><div>And the criteria to add a module in the trunk should not be the frequency of usage, but the quality of the code: I would like to see in the trunk any module well written, without bug even if seldom used.</div>
<div><br></div><div>Maxi<br><br><div class="gmail_quote">On Tue, Oct 30, 2012 at 10:44 PM, Martin Landa <span dir="ltr"><<a href="mailto:landa.martin@gmail.com" target="_blank">landa.martin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
2012/10/30 Helena Mitasova <<a href="mailto:hmitaso@ncsu.edu">hmitaso@ncsu.edu</a>>:<br>
<div class="im">> I agree with Glynn and Ben,<br>
> when working with students on 50+ different projects it is really great to have everything<br>
> in one package and not to worry about which additional tool to install and whether it will work with the latest release.<br>
> We used to have the code split into core, alpha and several other groups and it was pain to maintain,<br>
> I think it works much better now and the toolbox concept should be implemented at the GUI level.<br>
<br>
</div>sure on the other hand all GRASS modules included in trunk (or main<br>
branch) should be solid, well tested and actively *maintained*. Note<br>
that the GRASS development team is relatively small.<br>
<div class="im"><br>
> Maybe PSC should have some mechanism to decide on which add-ons to move to trunk based on a defined set of criteria.<br>
<br>
</div>We definitely need to define some criteria. Probably we should also<br>
review which addons modules should go to trunk (well written,<br>
maintained), and which should go from trunk to addons (not maintained,<br>
rarely used, seriously broken).<br>
<br>
>From my POV, r.modis or r.streams.* modules are examples of the<br>
modules which should go to trunk.<br>
<div class="im HOEnZb"><br>
Martin<br>
<br>
--<br>
Martin Landa <landa.martin <a href="http://gmail.com" target="_blank">gmail.com</a>> * <a href="http://geo.fsv.cvut.cz/~landa" target="_blank">http://geo.fsv.cvut.cz/~landa</a><br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- <br><br>Dr. Eng. Massimiliano Cannata<br>Responsabile Area Geomatica<br>Istituto Scienze della Terra<br>Scuola Universitaria Professionale della Svizzera Italiana<br>
Via Trevano, c.p. 72<br>CH-6952 Canobbio-Lugano<br>Tel: +41 (0)58 666 62 14<br>Fax +41 (0)58 666 62 09 <br>
</div>