[GRASS-dev] External providers in QGIS

[Moritz Lennert]

On 09/02/18 02:55, Nyall Dawson wrote:
> On 9 February 2018 at 00:20, Moritz Lennert
> <mlennert at club.worldonline.be> wrote:
>> On 08/02/18 15:08, Nikos Alexandris wrote:
>>>
>>> I guess, there are numerous cases like this one. What would,
>>> effectively, mean a removal of external providers (in this case GRASS
>>> GIS)?
>>
>>
>> Let's make it clear once and for all: noone is speaking about the complete
>> removal of external providers. The issue is where, how and by whom they
>> should be maintained, i.e. within the QGIS core code base, or as plugins.
>>
> 
> Yes, this is a great point. I think this discussion has got
> sidetracked with some misunderstandings.
> 
> Here's the situation as I see it:
> 
> ------------
> The past
> -----------
> 
> We (the QGIS project) have struggled to keep a bunch of providers
> stable and available with the base QGIS install, and the current
> maintainers (Alex and Victor, others) have (understandably) struggled
> with the burden of maintaining these alone and the time commitment
> required to do so. Users have been frustrated by breakage which occurs
> when the algorithms they depend on break due to changes in underlying
> libraries for which the processing providers have not been adapted.
> 
> Despite this, I'd say overall it's worked OK-ish up to now, but
> definitely with lots of room for improvement.
> 
> -------------
> The goals
> -------------
> 
> I think everyone involved is in agreement that processing's strength
> comes when there's many providers available and it's able to tie
> together processes regardless of which provider or library they come
> from. So I'd say our common goals are:
> 
> 1. Encourage development of as many processing providers as possible
> 2. Make it easy for developers to create and maintain these providers
> 3. Make it easy for users to be able to use the providers
> 4. Make everything stable and painfree for users
> 
> Any disagreements? No? Good ;)
> 
> So if we agree that those are the end goals, we should be using them
> to drive this discussion.
> 
> -------------------
> The questions
> -------------------
> 
> The open, debatable questions are:
> 
> - Which is the best approach for allowing easy maintenance of
> providers (*regardless* of whether the provider is maintained by the
> core QGIS team or a 3rd party)? Is it keeping the code in the master
> codebase and locking to QGIS releases, or publishing via plugins and
> having independent release schedules? Which approach will encourage
> more active maintenance of these providers and share the burden of
> this maintenance?
> 
> - Who should be responsible for maintaining the providers? Should
> maintenance be done by the QGIS core developer team or by 3rd parties?
> 
> - How do we make these tools available for ALL interested users? How
> can we ensure that 3rd party dependencies are always available and
> have a consistent feature set, regardless of which platform the user
> is running? Does having the QGIS team or 3rd parties maintain the
> provider help make the tools more readily available? Does having the
> providers in master or plugins make the 3rd party dependencies more
> readily available or not?
> 
> - How can we ensure that providers are well tested and don't break
> with changes in QGIS OR from 3rd party library updates? Does having
> the QGIS team or 3rd parties affect this stability? Does having the
> providers in master or plugins affect this stability?
> 
> - Is it a core requirement that 3rd party providers are installed with
> EVERY QGIS install, or is it acceptable to require interested users to
> manually install the tools which they find useful? If the second
> option is preferred, then how can we ensure that users are aware of
> the availability of these tools?
> 
> - Does it make it easier for everyone involved if we just delete all
> the python bindings for processing and only allow core, native, c++
> algorithms, and merge all our codebases into a single unified
> QGIS+SAGA+GRASS+OTB+R mega package? (I joke... ;)
> 
> This isn't an easy discussion, but please, let's keep the discussion
> civil, factual, and informed, and driven by the above goals.


Thanks for this summary, Nyall. It overlaps my summary in a parallel thread:

https://lists.osgeo.org/pipermail/grass-dev/2018-February/087420.html

Moritz