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

[Nyall Dawson]

Hi all,

Just wanted to raise a question I've been pondering lately.

Thanks to the success of the processing plugin, we're now seeing a lot
of 3rd party plugins which implement their functionality as processing
providers. (This is a great thing and hopefully we see more of this
when people port their plugins to 3.0!)

A lot of these provide useful functionality with quite small and
self-contained code. Here's a good example:
https://github.com/Septima/qgis-wedgebuffer
When you strip this plugin back it's basically 3/4 small functions
wrapped in a processing algorithm.

What I'm wondering now is whether we should be merging functionality
like this into master. In many ways the success of processing depends
entirely upon the amount (and quality!) of available algorithms. By
pulling the guts of these plugin based algorithms into master we allow
them to be used by all qgis users without the need to install extra
plugins.

The way I see it is:

Advantages:
- functionality available immediately from the default install
- by its nature processing algorithm code is very self-contained -
usually just a single file. We're not bloating the api by including
this functionality.
- processing has a strong framework for tests, so assuming suitable
tests are added when an algorithm is merged there's little extra
burden of maintenance here
- having this code in front of core developer's eyes likely leads to
improvements (in api & performance) for core c++ code. Speaking for
myself, I've pushed many fixes to the geometry engine as a direct
result of seeing how it's being used in processing algorithms.

Possible advantages:
- 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.

Disadvantages:
- more code in repo to maintain
- responsibility for fixes/improvements moves from plugin devs to qgis core devs
- plugin devs would need to go through PR process to implement
fixes/changes, and need to wait for next QGIS release for the changes
to be distributed

Possible disadvantages:
- 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!)

So what do we think? Good move? Bad move?

Nyall