On 9 February 2018 at 00:20, Moritz Lennert <[email protected]> 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. Nyall _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
