Re: [Qgis-developer] Complicate the plugin situation
2012/1/17 Alessandro Pasotti apaso...@gmail.com: Hi, after the latest discussions on this list and on the tracker the plugin situations has never been so confused. Yes, from my point of view I can confirm this From point of a plugin dev could be very useful an how to. I just terminate the creation of new subproject in the hub (I was wrong and I created a project instead a subproject of User Plugins so something could be improved) I try to summarize what I did until now for my plugin, could be useful for other developers: - on http://plugins.qgis.org the developer has to create a new plugin repository (http://plugins.qgis.org/plugins/add/) - on http://hub.qgis.org the developer can create a new subproject (I don't understand how) of qgis-user-plugins project and choose the modules that he want activate. That's all of my knowledge, I hope these are all the steps to do for the new qgis infrastructure -- best Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Complicate the plugin situation
Il 18/01/2012 12:25, Luca Delucchi ha scritto: That's all of my knowledge, I hope these are all the steps to do for the new qgis infrastructure Hi all. Thanks Luca. Could we write down an howto and put it on http://plugins.qgis.org/ ? All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Complicate the plugin situation
Il 18/01/2012 13:13, Paolo Cavallini ha scritto: I added a link from http://hub.qgis.org/projects/qgis-user-plugins to http://plugins.qgis.org/ - should be enough. Further suggestions welcome. Why not adding a link from http://qgis.org/ to http://plugins.qgis.org/ ? Also, in http://plugins.qgis.org/ why not adding to: * if you've found a bug in one of the plugins, learn how to submit a bug report a link to: http://hub.qgis.org/wiki/quantum-gis/Bugreports ? All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Complicate the plugin situation
On Wed, Jan 18, 2012 at 12:25 PM, Luca Delucchi lucadel...@gmail.com wrote: I try to summarize what I did until now for my plugin, could be useful for other developers: - on http://plugins.qgis.org the developer has to create a new plugin repository (http://plugins.qgis.org/plugins/add/) Correct, except for that you do not create a new *plugin repository*, you just create a *plugin* in the repository. I guess the source of confusion is that we refer to a *repository* in two different cases: 1. repository of plugins - where the plugins are stored for distribution (old at pyqgis.org, new at plugins.qgis.org) 2. source repository - where the plugin source code lives (svn/git) Idea: maybe we could use a different term for the plugin repository (meaning 1) ? Currently the popular online software repositories are called Android Market, Nokia's Ovi Store, Apple's App Store, Chrome Web Store and so on. Apparently a store is quite a good term, but maybe some less frequently used terms would work too... depot / ware house / emporium / haven ... or heaven? :) Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Complicate the plugin situation
QGIS plugin stash! - Nathan On Wed, Jan 18, 2012 at 10:41 PM, Martin Dobias wonder...@gmail.com wrote: Correct, except for that you do not create a new *plugin repository*, you just create a *plugin* in the repository. I guess the source of confusion is that we refer to a *repository* in two different cases: 1. repository of plugins - where the plugins are stored for distribution (old at pyqgis.org, new at plugins.qgis.org) 2. source repository - where the plugin source code lives (svn/git) Idea: maybe we could use a different term for the plugin repository (meaning 1) ? Currently the popular online software repositories are called Android Market, Nokia's Ovi Store, Apple's App Store, Chrome Web Store and so on. Apparently a store is quite a good term, but maybe some less frequently used terms would work too... depot / ware house / emporium / haven ... or heaven? :) Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Complicate the plugin situation
2012/1/18 Paolo Cavallini cavall...@faunalia.it: Il 18/01/2012 13:13, Paolo Cavallini ha scritto: I added a link from http://hub.qgis.org/projects/qgis-user-plugins to http://plugins.qgis.org/ - should be enough. Further suggestions welcome. Whoever needs write access to the welcome page (and any other static page) on http://plugins.qgis.org/ just log in once with his osgeo id on http://plugins.qgis.org and please tell me or any other admin. backend entry point is /admin/ -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Complicate the plugin situation
Il 18/01/2012 12:25, Luca Delucchi ha scritto: I try to summarize what I did until now for my plugin, could be useful for other developers: Notes added to http://plugins.qgis.org/ - please check and improve it if necessary. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Complicate the plugin situation
2012/1/18 Paolo Cavallini cavall...@faunalia.it: Il 18/01/2012 13:13, Paolo Cavallini ha scritto: I added a link from http://hub.qgis.org/projects/qgis-user-plugins to http://plugins.qgis.org/ - should be enough. Further suggestions welcome. Why not adding a link from http://qgis.org/ to http://plugins.qgis.org/ ? +1, maybe between Bugs and Shop Also, in http://plugins.qgis.org/ why not adding to: * if you've found a bug in one of the plugins, learn how to submit a bug report a link to: http://hub.qgis.org/wiki/quantum-gis/Bugreports ? +1 These changes are a good point of start, specially for user side, but not enough for developer -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Complicate the plugin situation
2012/1/18 Paolo Cavallini cavall...@faunalia.it: Notes added to http://plugins.qgis.org/ - please check and improve it if necessary. perfect!! thanks All the best. -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Complicate the plugin situation
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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Complicate the plugin situation
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. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
