[Qgis-developer] Complicate the plugin situation

[Martin Dobias]

Hi Alessandro

thanks for the summary!

> Discussion topics
> --------------------------
>
> Numbers refer to the items above.
>
> 1.1 - Recently, I've read about having another plugin home page on
> Redmine plugin subproject, what's the purpose of having another
> plugins list  on hub.qgis.org when we have the main repository on
> plugins.qgis.org. Do we really want to duplicate all? How will the two
> be kept in sync?

plugins.qgis.org should be the canonical list of plugins. The plugins
on hub.qgis.org do not have to be in 1:1 relation. I would not waste
time trying to keep them in sync.


> 1.3 In my view, the action of retrieving informations about the
> tracker URL or send a message to the author can be done through the
> Django application, either directly or through the QGIS client GUI via
> webservices. More complicated tasks like filing a ticket should be
> done from the users directly in the GUI of the application that the
> author has chosen as his preferred tracker system (see below).

Agreed. Providing links to plugin's home page and/or tracker should be
sufficient.


> 2.3/2.4 - forcing authors to use the Redmine SCM and tracker
> I strongly disagree: I don't think that having a single SCM code
> repository for all plugins is a priority, I myself I'm not going to
> use Redmine but will continue to host my plugins on github, will I be
> banned from the repository for that? What we can do (and we do it
> already) is to force authors to have *one* tracker and *one* code
> repository and we can suggest them to create one on Redmine. Set aside
> the freedom concerns, I understand that some plugins are over 10K LOC
> and a new release per week, but some others are just a few lines (and
> still very useful) and are not updated frequently, do their authors
> really need to learn complicated procedures in order to share a
> plugin? I even suspect that having a SCM should be mandatory, it
> doesn't always make sense for smaller plugins.

I completely agree with Alessandro.

The problem with plugins duplicating other plugins' work is not that
the plugin authors are unable to cooperate because plugins are
scattered everywhere. It is because coordinated development needs much
more time than a one man show.

> 2.2/2.3 - autopackaging and other black magic
>
> AN XML_RPC WEBSERVICE FOR THE UPLOAD OF NEW PLUGINS AND PLUGIN
> VERSIONS IS ALREADY AVAILABLE
>
> I personally think that every author will use its own Makefile/bash
> script/python script/lua script/say your script/ to perform the
> actions of bumping the version, packaging and uploading on the repo
> (YES: BELIEVE ME: THIS CAN BE DONE NOW FROM A SCRIPT VIA XML_RPC
> WEBSERVICE). What we can do is to add the few lines to call the upload
> ws (examples are available and already posted on this list) to the
> plugin creator plugin's makefile.

I hoped to build a plugin for plugin developers to facilitate some
development tasks, think FireBug for QGIS. The plugin would be shipped
 with QGIS (but disabled by default). The intended functionality:
- reload a plugin (integrate code from reloader from Borys)
- package+upload a plugin (using xml_rpc service from Alessandro)
- verbose python error reporting (show variable values in contexts)
- miscellaneous debugging tools

I did not have time to build such a thing yet. Any effort in this
direction would be welcome and it would further facilitate plugin
development.