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 _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer