Re: [Qgis-developer] The new QGIS plugin repo
Il 21/10/2010 23:46, Alex Mandel ha scritto: Maybe we need to re-ask, re-answer the questions: Who is the site for? What information should it contain? How much control do plugin authors need over their plugin? Let me also go back to basic: - we *need* a bug reporting system for plugins: this is very urgent IMHO - we need a collaboration platform: it would be so much better if we could fix each other's bugs, and collaborate merging now separated, possibly complementary, plugins. Sorry Pirmin, I do not understand when you write give away the control of ... source code; I understand however the need for a benevolent dictator for each plugin, but this should not mean impossibility to contribute code to it, IMHO - our users would like a documentation, popularity, and feedback system - we need simple systems, easy to administer, not to use too much resources in keeping the system going. Anything else? All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] The new QGIS plugin repo
Il 22/10/2010 12:51, Paolo Cavallini ha scritto: Let me also go back to basic: I would add: - having a cooperative platform in which one or more maintainer would group plugins under a reasonable number of submenus: now the situation is untenable, so difficult to find a plugin even if you know more or less what it is supposed to do that it is often easier to use the filter in the plugin installer. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] The new QGIS plugin repo
- should we require all plugins to be within this SVN repository or allow 'external' ones? My position is: this repo should be the standard, embedded in QGIS, but the user should be allowed to add any additional repo by hand. I may be wrong, of course. yes, there should be an option to add your own repository, just as it is currently the case. Often there are inhouse plugins (like a search or database metadata plugin) that is not of interest to the general public because it is tied to a certain infrastructure, or may even contain/or allow access to confidential information. These inhouse plugins should still be allowed to be distributed through an inhouse plugin repository as it is currently the case. - how to deal with official/contributed plugins? To me this distinction does not make much sense: I see core plugins (in trunk) and additional plugins (in the separate svn). Among the additional there will be all sort of nuances, from the very strong but of limited use to the proof-of-concept. It would be good if there could be some sort of quality assurance for plugins in the general, publically available repository. Not only because it may be bad press for QGIS if there are too experimental or poor quality plugins in the official repository, but also because it may help the user to see what plugins are popular and commonly used. Another issue is a minimum of documentation. This is a draw-back of the current system or situation. Often you install a plugin and you have no idea what it does. Just the name and the one-line description is not good enough. And often you don't know where the plugin ends up in the UI. Which is fine, if there is a quick intro. People need to know: * where is the UI of the plugin (menu location, toolbar, extensions of existing dialogues) * what the plugin really does. Sometimes, a one-line description is good enough, but quite often it is not * status of the plugin: experimental, production * a way to point to a website of the plugin (URL) for further information * who is the author: person, organization * are there support options specifically for the plugin? * additional documentation on the behavior of the plugin * maybe a way for users to comment/rate the plugin (only for registered users, to avoid spam) * a way to report bugs, feature requests on a plugin (trac?) * maybe a way to show HTML documentation/screenshots of the plugin in action in the plugin installer before installation of the plugin to inform the user if it is worth to install the plugin or not. One could embed qtwebkit for this purpose into the plugin installer * date metadata: when was the plugin released and last updated Just my opinions or expectations on a new plugin repo and, maybe related, an improved version of the installer. I think the current installer is very nice, but if the repo adds additional functionality it may have to be enhanced. All the best, Andreas -- Andreas Neumann http://www.carto.net/neumann/ http://www.svgopen.org/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] The new QGIS plugin repo
On 10/19/2010 03:37 PM, Paolo Cavallini wrote: Hi all. Am I the only one to perceive the need for a plugin trac+svn (or git)? If we decide we need it, it would be much better to have it in place before the hackfest, so we can start hacking around it in Wroklaw. + 1 from me for having centralized plugins repo and Trac for plugins. -- Ivan Mincik, Gista s.r.o. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] The new QGIS plugin repo
On Thu, 2010-07-01 at 21:18 -0500, Maxim Dubinin wrote: sounds good, Borys! I understand your concerns and support your idea. As there are quite many details and QAs already about new proposed plugin distribution system, it'd be nice to see it laid out as a single text and updated based on discussions, not to sift through dozen of emails. May be in wiki (sorry if it exists already and I missed it). Hi all, I started collecting ideas on http://www.qgis.org/wiki/Python_Plugin_Repositories edits welcome! cheers Anne Maxim Вы писали 1 июля 2010 г., 18:27:12: Dnia czwartek, 1 lipca 2010 o 19:49:19 napisałeś: We're currently hosting 11 plugins at our repo. The process is fully automated and once set up the author only commits to svn, all the other steps are done automatically using post-commit hooks. As for moving, unsure yet. I'm a big fan of diversity and ability of any person not only create a plugin, but distribute it the way (s)he likes or even irrationally wants. Erik Raymond has a good essay about this on Lockean rights. It is additional stimulation for a opensource developer to realize that this is _his_ territory. Centralized plugin repo will technically be the same, but psycologically somewhat different. That said, I can see a lot of value for a new author in this system. I'd say keep all options and let natural opensource selection do its job. This will introduce some hassle for Borys, but I believe it worth it for QGIS growth as not only software, but community. It's not a problem for me, but I believe hanging connections and error messages are not the best way to growth of the community ;-) I agree we (authors) fell better maintaining our own repositories, but we can't satisfy such needs at the users' expense! :) I see a sense in keeping your repository, what is always online, responsibly managed and quite rich. But we have 11 external repositories added by the 'add 3rd party repos' button. Most of them contains 2-3 plugins and cause most problems. Moreover, there are next 5 repos not included yet. It isn't fair that they are treated worse, but the more repos I add, the more often problems happen. So the compromise would be to offer to authors of small repositories a more convenient, robust and reliable solution and try to encourage them to join it. This way we can limit the number of external repositories added by the button to really necessary 3-5. Other Authors will have a choice: - to join the community repo - to maintain their own, but not included by the button - to maintain their own and justify it's reasonable to add it I understand the need of diversity, but users should trust that clicking this unfortunate button they won't be flooded by dozens unreliable repositories :) PS: I wrote a detailed description with scripts of our commit system sometime ago. If someone is interested (please use Google Translate panel on the left). http://gis-lab.info/qa/qgis-repo-update.html http://gis-lab.info/qa/qgis-repo.html Гугле панель суцкс. Я давна не читал русские буквы, но я пытаюсь что-то понять ;) Cпокойной ночи, goodnight! B. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- http://wiki.osgeo.org/wiki/Anne_Ghisla signature.asc Description: This is a digitally signed message part ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] The new QGIS plugin repo
Only as an user, I would like to help on this point but unfortunately I can't as I'm not a dev (which is my aim for the HF2012 ;) ). Move it for the HF2010! It's only Python, it doesn't bite! It swallows in whole... ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] The new QGIS plugin repo
Il 05/07/2010 08:49, Paolo Cavallini ha scritto: Il 02/07/2010 13:50, Carson Farmer ha scritto: Maybe this is simply too much work at this stage, but I'd like us to also consider other options... I think that we need: - a trac for plugin bugs - currently there is no reliable way to point out bugs and issues, to know which one was fixed, etc. - a way to cooperate on plugins: there are easy fix and improvements that cannot be applied because in the current structure only the owner of the plugin can; as a result, several forking has already occurred (which is bad both for devs and for users). Any further thoughts about this? I still think this is an important issue for the future of QGIS, and the sooner we deal effectively with it the better. I agree we should encourage, not discourage, individual contributions. On the other hand, we should make it easier to collaborate on the development and bugfixing of individual plugins. I see two choices here: - keeping the existing system, and create a script to sync the uploaded plugin to an ad hoc svn+trac: no impact on contributors, but we keep the possibility of fixing the plugins when needed, arranging them in menus and submenus, open tickets, etc. - replacing the current system with a different one, possibly with the seme or similar interface, that loads the plugin directly on the above mentioned svn+trac. Of course contributors can always add their repo at will: Our system should be in place just to help collaborating, not to force anyone. I'm sure there are other (better) options, and I'm looking forward for other suggestions. At the same time, a system for: - counting the number of downloads - giving a rank - sharing comments - sorting by popularity, number of downloads, date - tagging and searching is something useful, and everybody is expect such a system (see eg the FireFox addons: https://addons.mozilla.org/it/firefox/). All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] The new QGIS plugin repo
Le 15/08/2010 10:01, Paolo Cavallini a écrit : Il 05/07/2010 08:49, Paolo Cavallini ha scritto: At the same time, a system for: - counting the number of downloads - giving a rank - sharing comments - sorting by popularity, number of downloads, date - tagging and searching is something useful, and everybody is expect such a system (see eg the FireFox addons: https://addons.mozilla.org/it/firefox/). http://ghns.freedesktop.org/ http://www.kstuff.org/projects/hotstuff it used in kde to collect applets, scripts, themes, etc. and does all that you list ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] The new QGIS plugin repo
Il 15/08/2010 11:19, MORREALE Jean Roc ha scritto: http://ghns.freedesktop.org/ http://www.kstuff.org/projects/hotstuff it used in kde to collect applets, scripts, themes, etc. and does all that you list Looks good: what steps are necessary to integrate it in the current infrastructure? I think modifications to QGIS core should also be necessary, right? Jan Roc: would you be willing to further explore, and possibly implement, this? All the best, and thanks. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
