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

Victor Olaya volayaf at gmail.com
Mon Feb 6 01:21:36 PST 2017


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.

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

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


More information about the Qgis-developer mailing list