[Qgis-developer] Complicate the plugin situation

[Alessandro Pasotti]

Hi,

after the latest discussions on this list and on the tracker the
plugin situations has never been so confused.

This is a long email, please take a long breath and read it :)

I've been working on the new Plugin repository since the Lisbon
meeting, and I wish to summarize my (very personal) view about this
topic.

we have two actors: plugins users and plugins authors, let's call them

* users
* authors

we have a few of logical software tiers:

* QGIS client
* plugin repositories (let's focus on the "official" one)
* plugin code SCM repositories (git, mercurial, SVN let's focus on the
"official" one)
* plugin trackers
* website (for news, wiki, blogs, forums etc....)

This is the current implementation of the server tiers:

* plugin repository: Django application
* plugin code SCM repository: Redmine with integrated git SCM
* plugin trackers: Redmine
* website: scattered on the Django application and some other tools
(Joomla etc.)


There is currently no integration between Django app and Redmine, they
only share authentication via OSGEO LDAP.


1 User actions
---------------------

1.1 - search, browse available plugins
this can be done from the QGIS client GUI (via plugins.xml served by
the web Django application) or the web Django application which is the
ultimate source of data in any case.

1.2 - install plugins on the client, this can be done from the QGIS
client GUI (via plugins.xml served by the web Django application).

1.3 - report bugs, propose features, rate the plugin
this can be split in sub-actions (find the tracker URL if any or send
an email message o to the authorl etc. etc.).


2 Author actions
------------------------

2.1 - write the plugins: I cannot help you here, sorry ;-)
2.2 - upload the plugins on the repo
2.3 - maintain a SCM system
2.4 - manage tickets, fix bugs... maintain the code and interact with users


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?

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).

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.

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.

My conclusions
-----------------------

I think that Redmine is useful and can be used as the "suggested"
tracker and SCM system but we must allow authors to use an external
tracker or SCM if they like.
Integration between the Django application and Redmine is advisable
for the optional creation of new subprojects (tracker and SCM) if the
plugin author wants. I don't think that autopackaging worths some work
because I believe that every author does its own way and because it's
so easy to write a script that manages this on the author's client
machine.

Thanks if you read so far, I just hope that now the plugin situation
it's not more complicate than it was before :)

I'm looking forward to read your thoughts about this topics.

PS: I don't like dictators (even the benevolent ones)

-- 
Alessandro Pasotti
w3:   www.itopen.it