Re: [QGIS-Developer] External providers in QGIS

[Tim Sutton]

Hi Rashad

Thanks so much for your email below….sometimes things are not always easy to 
figure out, especially as QGIS gets bigger and more complex. We will really 
value your contribution as we move forward … and we will try to come up with a 
solution that works well for everyone.

Best regards

Tim

> On 20 Feb 2018, at 13:09, Rashad Kanavath  wrote:
> 
> Hello,
> 
> Sorry for the misunderstanding about my last mail, I didn't want to
> be disrespectful. I would like to continue the discussion about this
> contribution.
> 
> We will push this contribution and try to answer to all
> questions, comments or issues about it. We will submit with my colleagues in
> few days the QEP to have a strong basis for the discussion about this PR.
> Thanks for setting up discussion on external providers at QGIS developer 
> meeting.
> I had also registered to this discussion in github page.
> I hope that we can continue to work together in a constructive spirit on this 
> issue.
> 
> --
> Thanks,
> Rashad
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

—







Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux
IRC: timlinux on #qgis at freenode.net



signature.asc
Description: Message signed with OpenPGP
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

Hello,

Sorry for the misunderstanding about my last mail, I didn't want to
be disrespectful. I would like to continue the discussion about this
contribution.

We will push this contribution and try to answer to all
questions, comments or issues about it. We will submit with my colleagues in
few days the QEP to have a strong basis for the discussion about this PR.
Thanks for setting up discussion on external providers at QGIS developer 
meeting. 
I had also registered to this discussion in github page.
I hope that we can continue to work together in a constructive spirit on this 
issue.

-- 
Thanks,
Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Paolo Cavallini]

Il 08/02/2018 10:31, Rashad Kanavath ha scritto:

> I don't know what these developers are going to do with a bugfix after a
> new release. That's some kind of mystery unsolved to me.

we are doing regular point releases, an approach which has proven very
successful IMHO

> I hope there will be zero bugs after releases.

I hope you are joking :)

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=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 6:25 PM, Paolo Cavallini 
wrote:

> Il 07/02/2018 11:18, Victor Olaya ha scritto:
> > I dont see the advantage in having providers in core.
>
> I see the following:
> * tests (already available in our infrastructure)
> * translations
> * more exposure
> * documentation
>
> > And if there is an
> > advantage, it's clearly not in how easy it is going to be to maintain
> > the plugin.
>
> until now it has been maintained somehow; if more resources are needed,
> we can find a way
>
> > If the people responsible of a given backend (like OTB) are
> > going to maintain it (which makes sense), why putting it in core where
> > they don't have write access?
>
> why not granting them write access?
>
That would still need users *waiting* for QGIS release for fix in algo is
what I understood from other parts of discussion.
I don't know what these developers are going to do with a bugfix after a
new release. That's some kind of mystery unsolved to me.
I hope there will be zero bugs after releases.


>
> > Better in a separate repo. Also, they can
> > release whenever there are changes, without having to wait for a new
> > release. That way, the plugin will always be in sync with new releases
> > of the backend app.
>
> this is certainly true; AFAICT OTB people has proposed a solution


> > If we put them in core...why putting only this big ones (which in some
> > cases require installing external apps manually by the user), and not
> > put other plugins that exist and contain Processing providers?
>
> I'd be in favour of adding anything important for users.
>
> Thanks for your thoughts.
>
> When in Madeira we can have a discussion about this. It would be good if
> all interested parties could meet, locally and remotely.
>
> 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=IT=qgis,arcgis
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Paolo Cavallini]

Hi all,
I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
for serious, comprehensive GIS analysis work. Full stop.
Missing one specific alg, even if not used daily, means having to switch
to other software.
We have already removed R provider: even if used by a tiny minority, and
certainly not perfect, the previous situation was better than the
current one, without the option of using R from QGIS.
I think we have to be extra cautious on this ground.
All the best.

Il 07/02/2018 19:07, G. Allegri ha scritto:

> - from my experience - comprising years of feedbacks from the courses I
> teach - the most frequently used algs are available within the GDAL and
> QGIS algs list
> 
> - a few generic and widely used algs are from GRASS and SAGA. We would
> miss them - out of the box - but it could also be an opportunity to port
> them. For examples v.to.points, transects, profiles.
> Anyway we would have the plugins for GRASS and SAGA, in case...
> 
> - specific algs are for specialized users. Here I think plugins are best
> suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added to the
> list, consistently with the others approach.
> 
> I appreciate a lot the work from Richard, I hope this discussion is not
> understood as to belittle its effort!

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[G. Allegri]

I'm much more in favour for out of core providers, for the same reasons
reported by Victor. Having only GDAL and QGIS algorithms in core will
reduce the number of available algorithms out of the box, but:

- from my experience - comprising years of feedbacks from the courses I
teach - the most frequently used algs are available within the GDAL and
QGIS algs list

- a few generic and widely used algs are from GRASS and SAGA. We would miss
them - out of the box - but it could also be an opportunity to port them.
For examples v.to.points, transects, profiles.
Anyway we would have the plugins for GRASS and SAGA, in case...

- specific algs are for specialized users. Here I think plugins are best
suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added to the
list, consistently with the others approach.

I appreciate a lot the work from Richard, I hope this discussion is not
understood as to belittle its effort!

my 2 cents...
Giovanni

Il 7 feb 2018 18:25, "Paolo Cavallini"  ha scritto:

> Il 07/02/2018 11:18, Victor Olaya ha scritto:
> > I dont see the advantage in having providers in core.
>
> I see the following:
> * tests (already available in our infrastructure)
> * translations
> * more exposure
> * documentation
>
> > And if there is an
> > advantage, it's clearly not in how easy it is going to be to maintain
> > the plugin.
>
> until now it has been maintained somehow; if more resources are needed,
> we can find a way
>
> > If the people responsible of a given backend (like OTB) are
> > going to maintain it (which makes sense), why putting it in core where
> > they don't have write access?
>
> why not granting them write access?
>
> > Better in a separate repo. Also, they can
> > release whenever there are changes, without having to wait for a new
> > release. That way, the plugin will always be in sync with new releases
> > of the backend app.
>
> this is certainly true; AFAICT OTB people has proposed a solution
>
> > If we put them in core...why putting only this big ones (which in some
> > cases require installing external apps manually by the user), and not
> > put other plugins that exist and contain Processing providers?
>
> I'd be in favour of adding anything important for users.
>
> Thanks for your thoughts.
>
> When in Madeira we can have a discussion about this. It would be good if
> all interested parties could meet, locally and remotely.
>
> 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=IT=qgis,arcgis
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Paolo Cavallini]

Il 07/02/2018 11:18, Victor Olaya ha scritto:
> I dont see the advantage in having providers in core.

I see the following:
* tests (already available in our infrastructure)
* translations
* more exposure
* documentation

> And if there is an
> advantage, it's clearly not in how easy it is going to be to maintain
> the plugin.

until now it has been maintained somehow; if more resources are needed,
we can find a way

> If the people responsible of a given backend (like OTB) are
> going to maintain it (which makes sense), why putting it in core where
> they don't have write access?

why not granting them write access?

> Better in a separate repo. Also, they can
> release whenever there are changes, without having to wait for a new
> release. That way, the plugin will always be in sync with new releases
> of the backend app.

this is certainly true; AFAICT OTB people has proposed a solution

> If we put them in core...why putting only this big ones (which in some
> cases require installing external apps manually by the user), and not
> put other plugins that exist and contain Processing providers? 

I'd be in favour of adding anything important for users.

Thanks for your thoughts.

When in Madeira we can have a discussion about this. It would be good if
all interested parties could meet, locally and remotely.

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=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 3:03 PM, Victor Olaya  wrote:

> I dont think that it is possible to make it more generic. It's not only
> descriptors with only outputs and inputs. Each backend app has its own
> logic. GRASS needs outputs to be converted to its own format. SAGA accepts
> only SHP for vector layers and generates its own SDAT format for raster
> outputs. Parameters are also not passed in the same way to all apps. SAGA
> has extent parameters splitted in 4 params with bbox coordinates. Each
> provider has a different way of indicating a boolean value in the console
> call. In short, the logic must be there somehow, specific for the provider,
>

can you confirm that a GRASS input/output parameter can solve their issue?.
Still there is SAGA and other stuff. So generic provider is not something
QGIS team can do. But I would like to know about this on GRASS issue.


> What is the difference between maintaining a set of descriptor files (as
> you propose) and a set of descriptor files + a class extending
> GeoAlgorithmProvider with the logic (as it happens now)?. I think it is
> easier to have a solid provider class for OTB and then do not ever change
> it (assuming OTB syntax will never change), than having a generic provider,
> which looks rather unfeasible.
>
> Still OTB requires some changes in processing plugin to work. the old way
of twisting application only for QGIS must be avoided.
Without such a change there is no long-term existence even as plugin. Or
worse, it exists and will be broken.
QGIS must recognize such a behavior and avoid adding  burden on external
toolboxes' developer teams by asking for splitting applications. Be it OTB,
GRASS, SAGA whatever.

While I was at it, I saw there is less stuff to be managed and can be done
using a customwidgetwrapper for OTB. because a custom widget wrapper works
in a special way only for one provider.
Hence the idea of generic provider came up!.  In  case of GRASS its
input/output parameter, for OTB it is selection list parameter.

Thanks for your valuable feedback on this. I am sure an idea of generic
provider came up sometime during your work on processing plugin.
It tough and need more expert work and safe is to avoid it totally. I agree
on that part.



> As you say, there is the risk for dead code. In that case, i think it is
> much better to have the provider outside of QGIS core, as a plugin. There
> are dozens of dead plugins, and that is not nice, but it's kinda
> acceptable. Having dead code in QGIS it's a much bigger issue, and we must
> avoid that.
>
> Cheers
>
>
>
> 2018-02-07 14:41 GMT+01:00 Rashad Kanavath :
>
>> Hello victor,
>>
>> Do you see a possibility of a generic processing provider?. One that can
>> read descriptor files and run algorithms!.
>> I see processing as a single plugin (included in QGIS or not). And if it
>> can avoid need to have sub-plugin managed by all those other development
>> team. That's even better!.
>> Whichever toolbox want to be integrated into processing plugin can
>> provide and maintain descriptor files individually. No QGIS developers need
>> to be involved.
>> This way, external toolboxes' team or qgis does not need to maintain/fix
>> qgis--provider-plugin.
>>
>> search -> download -> install plugin will be changed to configure
>> providers install location.
>> If needed QGIS can control list of available providers (just names).
>>
>> External tools' dev team needs to know something such as spec of
>> descriptor files, how to mention name of executable etc.
>> They don't need to know stuff like how qgis run a processing algorithm,
>> and things working of modeler, running with other algorithms.
>>
>> Anyway, this is just an idea and don't know what will be technically
>> challenging issues?
>>
>> The other way of putting processing plugin into core and providers
>> classified as external plugins can avoid maintenance on qgis.
>> But this "strategy" can result in dead code and users complaining on both
>> projects. Because, at some developers cannot manage project release + a
>> plugin for qgis, another plugin for matlab or whatever
>> Putting all stuff in qgis tree and taking no responsibility of providers
>> isn't good either.
>>
>> This way, each team takes part and result in better collaboration and
>> contribution.
>> As time goes, generic descriptor provider gets better and stronger.
>> Toolboxes are free to add, remove, modify their applications and users from
>> both community benefit best of both worlds.
>>
>>
>> On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya  wrote:
>>
>>> I dont see the advantage in having providers in core. And if there is an
>>> advantage, it's clearly not in how easy it is going to be to maintain the
>>> plugin. If the people responsible of a given backend (like OTB) are going
>>> to maintain it (which makes sense), why putting it in core where they don't
>>> have write access? Better in a separate repo. Also, 

Re: [QGIS-Developer] External providers in QGIS

[Victor Olaya]

I dont think that it is possible to make it more generic. It's not only
descriptors with only outputs and inputs. Each backend app has its own
logic. GRASS needs outputs to be converted to its own format. SAGA accepts
only SHP for vector layers and generates its own SDAT format for raster
outputs. Parameters are also not passed in the same way to all apps. SAGA
has extent parameters splitted in 4 params with bbox coordinates. Each
provider has a different way of indicating a boolean value in the console
call. In short, the logic must be there somehow, specific for the provider,

What is the difference between maintaining a set of descriptor files (as
you propose) and a set of descriptor files + a class extending
GeoAlgorithmProvider with the logic (as it happens now)?. I think it is
easier to have a solid provider class for OTB and then do not ever change
it (assuming OTB syntax will never change), than having a generic provider,
which looks rather unfeasible.

As you say, there is the risk for dead code. In that case, i think it is
much better to have the provider outside of QGIS core, as a plugin. There
are dozens of dead plugins, and that is not nice, but it's kinda
acceptable. Having dead code in QGIS it's a much bigger issue, and we must
avoid that.

Cheers



2018-02-07 14:41 GMT+01:00 Rashad Kanavath :

> Hello victor,
>
> Do you see a possibility of a generic processing provider?. One that can
> read descriptor files and run algorithms!.
> I see processing as a single plugin (included in QGIS or not). And if it
> can avoid need to have sub-plugin managed by all those other development
> team. That's even better!.
> Whichever toolbox want to be integrated into processing plugin can provide
> and maintain descriptor files individually. No QGIS developers need to be
> involved.
> This way, external toolboxes' team or qgis does not need to maintain/fix
> qgis--provider-plugin.
>
> search -> download -> install plugin will be changed to configure
> providers install location.
> If needed QGIS can control list of available providers (just names).
>
> External tools' dev team needs to know something such as spec of
> descriptor files, how to mention name of executable etc.
> They don't need to know stuff like how qgis run a processing algorithm,
> and things working of modeler, running with other algorithms.
>
> Anyway, this is just an idea and don't know what will be technically
> challenging issues?
>
> The other way of putting processing plugin into core and providers
> classified as external plugins can avoid maintenance on qgis.
> But this "strategy" can result in dead code and users complaining on both
> projects. Because, at some developers cannot manage project release + a
> plugin for qgis, another plugin for matlab or whatever
> Putting all stuff in qgis tree and taking no responsibility of providers
> isn't good either.
>
> This way, each team takes part and result in better collaboration and
> contribution.
> As time goes, generic descriptor provider gets better and stronger.
> Toolboxes are free to add, remove, modify their applications and users from
> both community benefit best of both worlds.
>
>
> On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya  wrote:
>
>> I dont see the advantage in having providers in core. And if there is an
>> advantage, it's clearly not in how easy it is going to be to maintain the
>> plugin. If the people responsible of a given backend (like OTB) are going
>> to maintain it (which makes sense), why putting it in core where they don't
>> have write access? Better in a separate repo. Also, they can release
>> whenever there are changes, without having to wait for a new release. That
>> way, the plugin will always be in sync with new releases of the backend app.
>>
>> If we put them in core...why putting only this big ones (which in some
>> cases require installing external apps manually by the user), and not put
>> other plugins that exist and contain Processing providers?
>>
>> I thought the idea was to not have core plugins and avoid them if
>> possible. I don't see why we have to treat plugins that have Processing
>> provider in a different way. Specially considering how easy it is to
>> install a plugin in QGIS.
>>
>> Cheers
>>
>>
>>
>> 2018-02-06 18:57 GMT+01:00 Paolo Cavallini :
>>
>>> Hi all,
>>> following the discussion on qgis-dev ML:
>>> https://lists.osgeo.org/pipermail/qgis-developer/2018-Januar
>>> y/051701.html
>>> it has been proposed to remove all external providers (namely OTB,
>>> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will
>>> remain as QGIS cannot be built without). This raised a number of
>>> concerns, so PSC decided not to rush removing them from the upcoming 3.0
>>> release, and to open a wider discussions about this, involving all the
>>> interested parties, to find an optimal solution.
>>> If volunteers outside QGIS core team, ideally from the 

Re: [QGIS-Developer] External providers in QGIS

[Alexander Bruy]

Hi Rashad,

2018-02-07 15:41 GMT+02:00 Rashad Kanavath :
> Do you see a possibility of a generic processing provider?. One that can
> read descriptor files and run algorithms!.

This is possible in the ideal world of ponies and rainbows. In real
world we need
to deal with different types of the inputs, with different
representation of the same
thing in the different programs, different logics.

-- 
Alexander Bruy
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

Hello victor,

Do you see a possibility of a generic processing provider?. One that can
read descriptor files and run algorithms!.
I see processing as a single plugin (included in QGIS or not). And if it
can avoid need to have sub-plugin managed by all those other development
team. That's even better!.
Whichever toolbox want to be integrated into processing plugin can provide
and maintain descriptor files individually. No QGIS developers need to be
involved.
This way, external toolboxes' team or qgis does not need to maintain/fix
qgis--provider-plugin.

search -> download -> install plugin will be changed to configure providers
install location.
If needed QGIS can control list of available providers (just names).

External tools' dev team needs to know something such as spec of descriptor
files, how to mention name of executable etc.
They don't need to know stuff like how qgis run a processing algorithm, and
things working of modeler, running with other algorithms.

Anyway, this is just an idea and don't know what will be technically
challenging issues?

The other way of putting processing plugin into core and providers
classified as external plugins can avoid maintenance on qgis.
But this "strategy" can result in dead code and users complaining on both
projects. Because, at some developers cannot manage project release + a
plugin for qgis, another plugin for matlab or whatever
Putting all stuff in qgis tree and taking no responsibility of providers
isn't good either.

This way, each team takes part and result in better collaboration and
contribution.
As time goes, generic descriptor provider gets better and stronger.
Toolboxes are free to add, remove, modify their applications and users from
both community benefit best of both worlds.


On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya  wrote:

> I dont see the advantage in having providers in core. And if there is an
> advantage, it's clearly not in how easy it is going to be to maintain the
> plugin. If the people responsible of a given backend (like OTB) are going
> to maintain it (which makes sense), why putting it in core where they don't
> have write access? Better in a separate repo. Also, they can release
> whenever there are changes, without having to wait for a new release. That
> way, the plugin will always be in sync with new releases of the backend app.
>
> If we put them in core...why putting only this big ones (which in some
> cases require installing external apps manually by the user), and not put
> other plugins that exist and contain Processing providers?
>
> I thought the idea was to not have core plugins and avoid them if
> possible. I don't see why we have to treat plugins that have Processing
> provider in a different way. Specially considering how easy it is to
> install a plugin in QGIS.
>
> Cheers
>
>
>
> 2018-02-06 18:57 GMT+01:00 Paolo Cavallini :
>
>> Hi all,
>> following the discussion on qgis-dev ML:
>> https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html
>> it has been proposed to remove all external providers (namely OTB,
>> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will
>> remain as QGIS cannot be built without). This raised a number of
>> concerns, so PSC decided not to rush removing them from the upcoming 3.0
>> release, and to open a wider discussions about this, involving all the
>> interested parties, to find an optimal solution.
>> If volunteers outside QGIS core team, ideally from the respective
>> backends, could take the maintenance of these providers, not much would
>> change for the end user. If not, this will mean effectively missing
>> hundreds of algs from QGIS.
>> I personally propose to reinstate the OTB plugin with Rashad (from OTB)
>> as maintainer.
>> QGIS.ORG will seek to support any decision made with funding where
>> possible.
>> Looking forward for your feedback.
>> 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=IT=qgis,arcgis
>>
>
>


-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Victor Olaya]

I dont see the advantage in having providers in core. And if there is an
advantage, it's clearly not in how easy it is going to be to maintain the
plugin. If the people responsible of a given backend (like OTB) are going
to maintain it (which makes sense), why putting it in core where they don't
have write access? Better in a separate repo. Also, they can release
whenever there are changes, without having to wait for a new release. That
way, the plugin will always be in sync with new releases of the backend app.

If we put them in core...why putting only this big ones (which in some
cases require installing external apps manually by the user), and not put
other plugins that exist and contain Processing providers?

I thought the idea was to not have core plugins and avoid them if possible.
I don't see why we have to treat plugins that have Processing provider in a
different way. Specially considering how easy it is to install a plugin in
QGIS.

Cheers



2018-02-06 18:57 GMT+01:00 Paolo Cavallini :

> Hi all,
> following the discussion on qgis-dev ML:
> https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html
> it has been proposed to remove all external providers (namely OTB,
> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will
> remain as QGIS cannot be built without). This raised a number of
> concerns, so PSC decided not to rush removing them from the upcoming 3.0
> release, and to open a wider discussions about this, involving all the
> interested parties, to find an optimal solution.
> If volunteers outside QGIS core team, ideally from the respective
> backends, could take the maintenance of these providers, not much would
> change for the end user. If not, this will mean effectively missing
> hundreds of algs from QGIS.
> I personally propose to reinstate the OTB plugin with Rashad (from OTB)
> as maintainer.
> QGIS.ORG will seek to support any decision made with funding where
> possible.
> Looking forward for your feedback.
> 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=IT=qgis,arcgis
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer