[QGIS-Developer] Keeping OTB algorithm in qgis processing

[Victor Olaya]

+1 from me. This is exactly the reasoning behind my original proposal
of removing providers from core. Whether the plugin is easy to
maintain or not, it is better to do it outside. People responsible of
the plugin can release whenever they want, and they can do changes
without having to do PRs to the main repo (so less burden for core
devs)

A plugin with a provider has much more to do with the provider app
than with QGIS, and it makes sense to maintain it as a separate thing,
and, if possible, done by the people that better know the external app
(like the OTB team in the case of OTB)

Cheers

2018-02-01 0:17 GMT+01:00 Nyall Dawson <nyall.dawson at gmail.com>:
> On 31 January 2018 at 20:23, Alexander Bruy <alexander.bruy at gmail.com> wrote:
>> Another reason to remove providers is that algorithms descriptions
>> were not updated and maintained. Even now both SAGA and GRASS
>> providers are not updated to latest stable versions of the corresponding
>> software.
>>
>> We just simply does not have enough resources to maintain more than
>> 600 algorithms from GRASS and SAGA. Situation with OTB, was even
>> worse, it requires special handling of the parameters.
>>
>> I still think that Processing should be in core with minimal set of algorithms
>> (native and GDAL), all other providers should be plugins and installed by
>> users. Ideally these providers also should be maintained by interested groups
>> of devs/users, not by QGIS devs.
>
> A big +1 to everything Alex said above, and a strong -1 to
> reintroducing any of these providers back to master (and also a +1 to
> shifting the SAGA provider to a non-default plugin).
>
> My reasons:
>
> - we have a very strong plugin infrastructure designed EXACTLY for
> these use cases. Having these providers as separate plugins, free from
> the QGIS release cycle makes a ton of sense. Plugins devs can then
> push new versions of their providers whenever new versions of the
> underlying libraries are available, and not be constrained by waiting
> until the next QGIS release.
>
> - years of experience has PROVEN that we do not have the capacity to
> maintain these providers ourselves. Numerous developers have tried,
> and just been swamped by the amount of work required to keep the
> providers stable while the underlying libraries change. The QGIS team
> is running at capacity just keeping QGIS maintained and stable - we
> CANNOT take on this extra work.
>
> - regardless of the approach taken, things just don't stay stable for
> us. E.g. we tried to make the SAGA provider more stable by only
> targeting the SAGA LTR release.... yet the SAGA upstream seem to have
> abandoned the LTR, leaving it totally broken on newer build chains. I
> cannot get SAGA LTR to run on my development platform (Fedora) as it
> constantly segfaults. End result - even if I had the time to maintain
> this provider, I would be totally unable to. (For this reason I think
> SAGA should also be moved to a separate QGIS plugin, leaving on QGIS,
> GDAL and GRASS provided in the default install. GDAL and GRASS
> (mostly) are always available wherever QGIS is.).
>
> - While QGIS 3.0 has introduced big changes for processing, these are
> likely to be the last big changes processing providers will see for
> the future. At least for the next 3-4 years (or lifetime of 3.x) the
> API will be fixed. And even following that, I'd envision any breaks
> introduced in 4.0 to be much less extreme. So while it's painful for
> plugins to update their providers for 3.0, it's a one-time pain. In
> contrast, expecting QGIS devs to follow the numerous underlying
> library changes and version breaks for multiple 3rd party dependancies
> is exhausting, ongoing work. It's much more sensible for someone
> intimately familiar with those libraries to maintain a plugin which
> closely tracks the library development and follow best-practice API
> use for that library.
>
>
> Nyall
>
>
>
>>
>> 2018-01-31 12:17 GMT+02:00 Victor Olaya <volayaf at gmail.com>:
>>> The original idea was to have most providers removed...which included
>>> R, GRASS and SAGA as well. Finally, only certain providers were
>>> removed, mostly those that require dependencies not provided with QGIS
>>> (LiDAR tools, R...and OTB)
>>>
>>> If maintaining the plugin is complicated and no work is done on that,
>>> then definitely it is better to keep it as core. But we have to make
>>> sure that the user knows that the provider by itself is useless, and
>>> that OTB has to be installed separately. Otherwise, we will see
>>> confusion and i think it will not be a good idea
>>>
>>> My 2 cents
>>>
>>> 2018-01-31 11:04 GMT+01:00 Paolo Cavallini <cavallini at faunalia.it>:
>>>> Il 31/01/2018 09:50, Rashad Kanavath ha scritto:
>>>>
>>>>> Thanks Paolo,
>>>>> Can you give a link to that discussion?
>>>>
>>>> I had a look to the archives, and I only found this:
>>>> https://lists.osgeo.org/pipermail/qgis-developer/2017-May/048470.html
>>>> Surely Victor and Alex can provide further details.
>>>> All the best.
>>>>
>>>> --
>>>> Paolo Cavallini - www.faunalia.eu
>>>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>>>> https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
>>
>>
>>
>> --
>> Alexander Bruy
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer