[Qgis-developer] Processing algs & plugins... should we actively pull into master?

[Tim Sutton]

Hi

> On 06 Feb 2017, at 11:21 AM, Victor Olaya <volayaf at gmail.com> wrote:
> 
> Very interesting question...
> 
> IMHO, all plugins that include processing algorithms like that (just
> one of them or a few of them, using only native code), we should ask
> developers to put the code in the central QGIS repo, and then work on
> that through PRs. It makes more sense. In the case of a plugin that
> adds a large group of algorithms and has some "identity", or uses an
> external app, I think it makes sense to have it as a separate plugin.

Or even just a discrete group in the Processing toolbox?

> 
> I think most developers will agree on that and will accept it. If
> someone doesnt....well, then we have that code as a separate plugin,
> not that bad, but with those that accept, we will enlarge the core
> Processing collection and make it better.
> 
> Just let make sure that we have some clear acceptance criteria (algs
> with tests, trying to follow some "best practices" and using
> Processing methods when possible, etc).
> 
> I will be happy to help on that, even helping devs in this migration
> from separate plugin to core Processing, in case there is a need to
> convert code somehow
> 

I know there is a bit of philosophical thinking to be done as to whether we want to be a 'slim core' project or a 'batteries included' project. I generally prefer the batteries included approach if we can make features discoverable and consistent with the rest of the QGIS experience. So +1 from me to build out processing into a much richer store of tools.  One more argument for including new algs in processing in QGIS Master rather than as plugins - if we want plugin authors to utilize processing more, it is much more convenient that the algs are all there 'out of the box' compared to expecting plugin users to install other plugins in order to first satisfy processing dependencies.

One thing I am concerned about is that we guarantee some stability in the behavior of processing. While it is true that strictly speaking new algorithms do not represent API extensions / additions, in some level I think they do since anyone using Python + Processing will be vulnerable to future behavioral changes / deletions from the set of tools shipped with processing. If we want to get plugin writers to rely on Processing rather than implementing geoprocessing etc.  functionality themselves, they need to know that a) the algorithms they need will be installed on their user's computers and b) that those algorithms will behave in a consistent way across the major release life cycle of QGIS.

Regards

Tim


> Cheers
> 
> 
> 2017-02-06 9:46 GMT+01:00 Paolo Cavallini <cavallini at faunalia.it>:
>> Il 06/02/2017 00:55, Nyall Dawson ha scritto:
>> 
>>> What I'm wondering now is whether we should be merging functionality
>>> like this into master.
>> 
>> +1, thanks for raising this.
>> 
>>> - might be a good spring-board for easing plugin developers into
>>> working with the master repo. There's a chance they'll find confidence
>>> in this to make changes elsewhere in the code.
>> 
>> exactly, I'm always trying to convince plugin developers to jump in the
>> bandwagon, this move would be a strong argument for it.
>> 
>>> fixes/changes, and need to wait for next QGIS release for the changes
>>> to be distributed
>> 
>> a general issue with Processing, and other core plugins BTW.
>> better discuss about this in general terms.
>> 
>>> - we risk "stepping on plugin developer's toes". It's possible a
>>> plugin developer might not like seeing the role their plugin once
>>> played "taken over" by master. (On the other hand, they may be proud
>>> to see their work accepted into the default install!)
>> 
>> this is a possibility; in my experience however it can be avoided by
>> proper communication with plugin authors. for what I have seen, plugin
>> authors are pleased by the interest we have in their work, so I think
>> we'll encounter no major problems here. I can keep on taking the
>> responsibility of communicating to plugin authors if nobody wants to
>> step in.
>> 
>>> So what do we think? Good move? Bad move?
>> 
>> good by all means.
>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> 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

—










Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com <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

Kartoza is a merger between Linfiniti and Afrispatial

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170206/1ec3a25f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KartozaNewLogoThumbnail.jpg
Type: image/jpeg
Size: 6122 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170206/1ec3a25f/attachment-0001.jpg>