<div dir="ltr"><div>Hello,</div><div><br></div>Processing plugin allows to integrate other toolboxes. IIUC, this was one of the features of it. <div>So when you say integration of so and so toolboxes are total mess, you might think back.<div><br></div><div>Nobody had seen new changes to otb algs so all of your comments are on old version.  Why so rush? </div><div>Okay, it easy to reject stating the same reason over and over again. I understand that.</div><div>What happens at end, a processing plugin with zero providers?</div><div><br></div><div>Now the reason OTB had to maintain list of "supported" version is due the fact that processing plugin does not allow to group parameters. </div><div>So the issue of a provider being total mess not fully related to provider itself. If 90% of provider algorithm which you use, cannot be even</div><div>integrated into processing where will be the actual problem. I see a lot of good changes in qgis processing and providers can greatly benefit from it now.</div><div><br></div><div>All those people blindly rejecting this proposal should have waited for new changes. </div><div>I mean, I just put a proposal to lower the burden as much as possible. And all those issues raised by Alex, Nyall and others will be considered in the new diff.</div><div>Once I prepare changes, you can reject it!. You are voting -1ss on old plugin code something I consider a mess to work with for both teams.</div><div><br></div><div>My initial question was only to see if there are other issues than the maintenance overhead?</div><div>By now, I conclude that only issue was maintenance overhead and I proposed it can be solved.<br></div><div><br></div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 1, 2018 at 12:17 AM, Nyall Dawson <span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 31 January 2018 at 20:23, Alexander Bruy <<a href="mailto:alexander.bruy@gmail.com">alexander.bruy@gmail.com</a>> wrote:<br>
> Another reason to remove providers is that algorithms descriptions<br>
> were not updated and maintained. Even now both SAGA and GRASS<br>
> providers are not updated to latest stable versions of the corresponding<br>
> software.<br>
><br>
> We just simply does not have enough resources to maintain more than<br>
> 600 algorithms from GRASS and SAGA. Situation with OTB, was even<br>
> worse, it requires special handling of the parameters.<br>
><br>
> I still think that Processing should be in core with minimal set of algorithms<br>
> (native and GDAL), all other providers should be plugins and installed by<br>
> users. Ideally these providers also should be maintained by interested groups<br>
> of devs/users, not by QGIS devs.<br>
<br>
</span>A big +1 to everything Alex said above, and a strong -1 to<br>
reintroducing any of these providers back to master (and also a +1 to<br>
shifting the SAGA provider to a non-default plugin).<br>
<br>
My reasons:<br>
<br>
- we have a very strong plugin infrastructure designed EXACTLY for<br>
these use cases. Having these providers as separate plugins, free from<br>
the QGIS release cycle makes a ton of sense. Plugins devs can then<br>
push new versions of their providers whenever new versions of the<br>
underlying libraries are available, and not be constrained by waiting<br>
until the next QGIS release.<br>
<br>
- years of experience has PROVEN that we do not have the capacity to<br>
maintain these providers ourselves. Numerous developers have tried,<br>
and just been swamped by the amount of work required to keep the<br>
providers stable while the underlying libraries change. The QGIS team<br>
is running at capacity just keeping QGIS maintained and stable - we<br>
CANNOT take on this extra work. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- regardless of the approach taken, things just don't stay stable for<br>
us. E.g. we tried to make the SAGA provider more stable by only<br>
targeting the SAGA LTR release.... yet the SAGA upstream seem to have<br>
abandoned the LTR, leaving it totally broken on newer build chains. I<br>
cannot get SAGA LTR to run on my development platform (Fedora) as it<br>
constantly segfaults. End result - even if I had the time to maintain<br>
this provider, I would be totally unable to. (For this reason I think<br>
SAGA should also be moved to a separate QGIS plugin, leaving on QGIS,<br>
GDAL and GRASS provided in the default install. GDAL and GRASS<br>
(mostly) are always available wherever QGIS is.).<br>
<br>
- While QGIS 3.0 has introduced big changes for processing, these are<br>
likely to be the last big changes processing providers will see for<br>
the future. At least for the next 3-4 years (or lifetime of 3.x) the<br>
API will be fixed. And even following that, I'd envision any breaks<br>
introduced in 4.0 to be much less extreme. So while it's painful for<br>
plugins to update their providers for 3.0, it's a one-time pain. In<br>
contrast, expecting QGIS devs to follow the numerous underlying<br>
library changes and version breaks for multiple 3rd party dependancies<br>
is exhausting, ongoing work. It's much more sensible for someone<br>
intimately familiar with those libraries to maintain a plugin which<br>
closely tracks the library development and follow best-practice API<br>
use for that library.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Nyall<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
><br>
> 2018-01-31 12:17 GMT+02:00 Victor Olaya <<a href="mailto:volayaf@gmail.com">volayaf@gmail.com</a>>:<br>
>> The original idea was to have most providers removed...which included<br>
>> R, GRASS and SAGA as well. Finally, only certain providers were<br>
>> removed, mostly those that require dependencies not provided with QGIS<br>
>> (LiDAR tools, R...and OTB)<br>
>><br>
>> If maintaining the plugin is complicated and no work is done on that,<br>
>> then definitely it is better to keep it as core. But we have to make<br>
>> sure that the user knows that the provider by itself is useless, and<br>
>> that OTB has to be installed separately. Otherwise, we will see<br>
>> confusion and i think it will not be a good idea<br>
>><br>
>> My 2 cents<br>
>><br>
>> 2018-01-31 11:04 GMT+01:00 Paolo Cavallini <<a href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</a>>:<br>
>>> Il 31/01/2018 09:50, Rashad Kanavath ha scritto:<br>
>>><br>
>>>> Thanks Paolo,<br>
>>>> Can you give a link to that discussion?<br>
>>><br>
>>> I had a look to the archives, and I only found this:<br>
>>> <a href="https://lists.osgeo.org/pipermail/qgis-developer/2017-May/048470.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>pipermail/qgis-developer/2017-<wbr>May/048470.html</a><br>
>>> Surely Victor and Alex can provide further details.<br>
>>> All the best.<br>
>>><br>
>>> --<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>
><br>
><br>
><br>
> --<br>
> Alexander Bruy<br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
______________________________<wbr>_________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div></div>
</div></div></div></div>