[Qgis-developer] Complicate the plugin situation

[Paolo Cavallini]

Il 17/01/2012 10:01, Alessandro Pasotti ha scritto:

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

Agreed.

> 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?

Right, please avoid duplication. We should make it easy to find the "right" page, and 
remove (or hide) others.

> 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 do not think anybody ever suggested to force anybody to do anything.
My opinion:
- we should have a standard path, fully automatic, to make life easy for plugin writers
- if anybody wants to follow alternative routes, this must be possible
- an SCM is always good, as it makes easier to cooperate; we already have plugins 
that need small fixes, and we'll have more in the near future, due to API breakage; 
sometimes plugin writers are not very responsive, so others could quickly fix a 
broken plugin (and it is far easier to fix them all once one knows which API is 
broken than forcing many authors to learn how to do it)
- a bugtracker of some sort is a requirement: I think nobody wants to use software 
without a proper bug tracking system

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

OK, this seems the best solution. As you imply, it is currently rather hidden for 
authors.

In general, I think we should better document the whole process, that now looks far 
more complicated than it is.

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

+1

> Integration between the Django application and Redmine is advisable
> for the optional creation of new subprojects (tracker and SCM) if the
> plugin author wants.

+1

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

-1: remeber that what is very easy for one can be a stumbling block for others; for 
several authors, writing a QGIS-py plugin is one of the first serious programming 
tasks they encounter, so let's make their life easier.
Anyway, I think most of the issues (if not all) can be fixed with proper, clear, and 
easy to find documentation of the whole process (a complete howto from scratch): any 
volunteer?

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

I think nobody likes them here (and this is one of the reasons why working on QGIS is 
such a pleasure).

All the best, and thanks Alessandro for your work and commitment to the project.

-- 
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc