<div dir="ltr">Thank you, Paolo, for the summary. It was great to be part of the meeting!<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 23, 2018 at 9:26 AM, Paolo Cavallini <span dir="ltr"><<a href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
meeting has just ended. I must say it was a very interesting and<br>
productive discussion. We are really grateful for the developers from<br>
GRASS, SAGA and OTB for their contributions to our discussion.<br>
I recap briefly here what I believe are the most important outcomes:<br>
* we'll keep SAGA and GRASS Processing providers<br>
* we'll try to update SAGA provider to the next LTR when this will be<br>
available<br>
* we invite OTB team to add their work to QGIS core, granting them write<br>
access if they wish<br>
* for OTB provider, considering that OTB binaries are not part of the<br>
installer on Windows, we suggest this approach: OTB provider checks<br>
whether OTB is installed, if not it suggests the user to install it, if<br>
the user does not the provider hides itself<br>
* While we have granted an exception to the ‘processing providers should<br>
not be in core’ for the short term, our longer term plan is to put in<br>
place mechanisms to ‘side load’ the dependencies (GRASS, OTB, SAGA).<br>
When this capability is implemented, we will mandate that all providers<br>
will be provided as plugins and then fetch these plugins on demand if an<br>
algorithm references them<br>
* we will not accept new providers, unless some very strict and<br>
exceptional conditions apply (TBD; e.g. new backend of high quality and<br>
general usage)<br>
* for future versions we will consider moving providers to the XML<br>
approach where appropriate, as it appears more maintainable, even at the<br>
expense of flexibility in interface tuning; GRASS is the next candidate,<br>
noting that this might require some modifications in GRASS core<br>
* as a first step in we ask anybody to test thoroughly the new SAGA<br>
provider by Alex Bruy<br>
<a href="https://github.com/alexbruy/processing-saga" rel="noreferrer" target="_blank">https://github.com/alexbruy/<wbr>processing-saga</a><br>
also a check from SAGA, GRASS, and OTB devs would be important, to check<br>
whether this approach is the preferred one from all sides.<br>
Please add if I missed something.<br>
Overall, I think we have now a brighter future for Processing, and as a<br>
consequence for QGIS, SAGA, GRASS and OTB altogether.<br>
* If you want to watch the complete discussion, please be patient; video<br>
is being uploaded.<br>
All the best, and thanks again.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" target="_blank">www.faunalia.eu</a><br>
QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" rel="noreferrer" target="_blank">http://www.faunalia.eu/<wbr>training.html</a><br>
<a href="https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis" rel="noreferrer" target="_blank">https://www.google.com/trends/<wbr>explore?date=all&geo=IT&q=<wbr>qgis,arcgis</a><br>
______________________________<wbr>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a></font></span></blockquote></div><br></div>