Re: [Qgis-user] Public Repository for plugins...
thanks a lot for enabling the experimental plugins with options tab in the python fetch plugins. could it be also possible to indicate that the plugin is either stable or unstable somewhere in the grid maybe as a new field in the plugins tab. it will be good to know which one is experimental plugin after enabling and before installing. On Tue, Jun 16, 2009 at 3:24 PM, Borys Jurgiel-2 (via Nabble) ml-user+174773-357162...@n2.nabble.comml-user%2b174773-357162...@n2.nabble.com wrote: Tuesday 16 of June 2009 08:47:06 Volkan Kepoglu napisał(a): it is very good opportunity to create two repos for the same plugin. One for stable and one for experimental purposes. You can either create the two repos and recommend the unstable one only for 'experimenting' users, or put two plugin instances to one repo and mark one as experimental. For those, who didn't enable experimental plugins, how can we enable the experimental plugins in the qgis in order to fetch the plugin from repo if the repo is tagged as experimental? Wait, whole repo can't be tagged as experimental. Is there such need? In fact, I would prefer to avoid such complications... Is there Luiz P. Motta reading me? :) Pleeease, correct the version number of your plugin :) ___ Qgis-user mailing list qgis-u...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=3086023i=0 http://lists.osgeo.org/mailman/listinfo/qgis-user -- View message @ http://n2.nabble.com/Public-Repository-for-plugins...-tp3045029p3086023.html To start a new topic under qgis-user, email ml-node+2036571-634870...@n2.nabble.comml-node%2b2036571-634870...@n2.nabble.com To unsubscribe from qgis-user, click here (link removed) =. -- Regards, Volkan Osman Kepoglu PhD Candidate GGIT Department in METU, Ankara, Turkey. -- View this message in context: http://n2.nabble.com/Public-Repository-for-plugins...-tp3045029p3115457.html Sent from the qgis-user mailing list archive at Nabble.com. ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Public Repository for plugins...
it is very good opportunity to create two repos for the same plugin. One for stable and one for experimental purposes. For those, who didn't enable experimental plugins, how can we enable the experimental plugins in the qgis in order to fetch the plugin from repo if the repo is tagged as experimental? -- View this message in context: http://n2.nabble.com/Public-Repository-for-plugins...-tp3045029p3084708.html Sent from the qgis-user mailing list archive at Nabble.com. ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Public Repository for plugins...
Tuesday 16 of June 2009 08:47:06 Volkan Kepoglu napisał(a): it is very good opportunity to create two repos for the same plugin. One for stable and one for experimental purposes. You can either create the two repos and recommend the unstable one only for 'experimenting' users, or put two plugin instances to one repo and mark one as experimental. For those, who didn't enable experimental plugins, how can we enable the experimental plugins in the qgis in order to fetch the plugin from repo if the repo is tagged as experimental? Wait, whole repo can't be tagged as experimental. Is there such need? In fact, I would prefer to avoid such complications... Is there Luiz P. Motta reading me? :) Pleeease, correct the version number of your plugin :) ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
RE: [Qgis-user] Public Repository for plugins...
Well, I assume that the two plugins I posted will remain in the wild as they are designed from a tester's point of view and from an educational point of view. I would say that plugins that are general enough to benifit ,majority of QGIS users make it to the core. For the other SPECIALIZED plugins a group to review them might be a good idea. I imagine that most of this would depend on the community, for prolific authors might hold more weight than the one times and the learners. A process that merely checks off criteria versus worthiness might make a lot of sense. Making the process objective instead of subjective. Just some thoughts. Cheers -Original Message- From: qgis-user-boun...@lists.osgeo.org [mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of Alex Mandel Sent: Monday, June 15, 2009 22:07 To: Borys Jurgiel Cc: qgis-user@lists.osgeo.org Subject: Re: [Qgis-user] Public Repository for plugins... Borys Jurgiel wrote: Monday 08 of June 2009 22:42:34 Dane Springmeyer napisał(a): Funny - how is it that there are only two 'official plugins'? Yes - nobody is keen to form a High Committee and evaluate plugins... :( I don't think too many people have asked, besides that it seems that plugins that are really good end up in the core code most of the time and don't exist as separate plugins for long. Alex ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
RE: [Qgis-user] Public Repository for plugins...
Just as I am going through a pseudo code exercise of release.py I see three cases. 1. Current and previous stable versions VERSION 2. A Beta version is is being tested an on its way to stable. BETA 3. An unstable snapshot of the development trunkALPHA If we assume that most new feature development is done in the branches and merged to trunk, then trunk should not be all the harry and trashy. The branches would be way to unstable. This way then regular users can try unstable and beta version of the plugins wihtout needing to get into SVN carnage. For now I will call trunk snapshots BETA Just some thoughts. -Original Message- From: qgis-user-boun...@lists.osgeo.org [mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of Borys Jurgiel Sent: Monday, June 15, 2009 19:15 To: qgis-user@lists.osgeo.org Subject: Re: [Qgis-user] Public Repository for plugins... Monday 08 of June 2009 22:03:47 Sampson, David napisał(a): Maybe those that are interested can have a little thread and come up with a temp solutions while the ducks line up... I would propose sourceforge as that is what I know and I already help admin a project on sourceforge. I would say if we can get three plugin groups working together that is a good start. Any takers? This is good idea. The present state of multi-instance plugins I've tried to explain in my previous post. In general, you can add to your repository two instances of the same plugin: pyqgis_plugin version=0.1 name=Foo Plugin descriptionSome description/description homepagehttp://foo/homepage qgis_minimum_version1.0/qgis_minimum_version file_namefoo.zip/file_name author_nameSomeone/author_name download_urlhttp://some_url/some_dir/foo.zip/download_url /pyqgis_plugin pyqgis_plugin version=0.2-beta name=Foo Plugin descriptionSome description/description homepagehttp://foo/homepage qgis_minimum_version1.0/qgis_minimum_version file_namefoo.zip/file_name author_nameSomeone/author_name download_urlhttp://some_url/another_dir/foo.zip/download_url experimentaltrue/experimental /pyqgis_plugin Note that there are two plugins foo.zip. The latter one has higher version number, but is marked with the optional tag experimental. It means, that will be chosen as the 'best available' for all users allowing experimental plugins. For those, who didn't enable experimental plugins, the former plugin will be chosen. Similarly, you can publish one instance for QGIS=1.0 and another one for QGIS =1.1 Just remember to give a higher version for the latter one and installer choose the highest one if the =1.1 requirement is fulfilled. Note that both files are named foo.zip, so you can't put them together to the main contributed repository, as they all are stored in one directory there. But you can use the suffix I mentioned in my previous mail: foo.zip containing the directory foo foo.beta.zip containing the same directory foo Oh, the main repository doesn't handle the 'experimental' tag yet, AFAIK? But I hope it will be implemented soon. Note that there are only two levels of stability: experimental or not. It has been discussed whether we need more and realized that just don't. Please remember that there are so many authors with different opinions and different willingness to keep metadata accurate ;) that I found keeping it as simple as possible reallyu essential :) ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
RE: [Qgis-user] Public Repository for plugins...
For a community plugin repo I assume that multiple authors might be involved in the development of a plugin For the element... author_nameSomeone/author_name Can this be a comman separated value. I am thinking of automaticaly generating this from an AUTHORS.txt file Also, is there an e-mail optio we can add or what about a URL to an AUTHORS file? Cheers -Original Message- From: qgis-user-boun...@lists.osgeo.org [mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of Borys Jurgiel Sent: Monday, June 15, 2009 19:15 To: qgis-user@lists.osgeo.org Subject: Re: [Qgis-user] Public Repository for plugins... Monday 08 of June 2009 22:03:47 Sampson, David napisał(a): Maybe those that are interested can have a little thread and come up with a temp solutions while the ducks line up... I would propose sourceforge as that is what I know and I already help admin a project on sourceforge. I would say if we can get three plugin groups working together that is a good start. Any takers? This is good idea. The present state of multi-instance plugins I've tried to explain in my previous post. In general, you can add to your repository two instances of the same plugin: pyqgis_plugin version=0.1 name=Foo Plugin descriptionSome description/description homepagehttp://foo/homepage qgis_minimum_version1.0/qgis_minimum_version file_namefoo.zip/file_name author_nameSomeone/author_name download_urlhttp://some_url/some_dir/foo.zip/download_url /pyqgis_plugin pyqgis_plugin version=0.2-beta name=Foo Plugin descriptionSome description/description homepagehttp://foo/homepage qgis_minimum_version1.0/qgis_minimum_version file_namefoo.zip/file_name author_nameSomeone/author_name download_urlhttp://some_url/another_dir/foo.zip/download_url experimentaltrue/experimental /pyqgis_plugin Note that there are two plugins foo.zip. The latter one has higher version number, but is marked with the optional tag experimental. It means, that will be chosen as the 'best available' for all users allowing experimental plugins. For those, who didn't enable experimental plugins, the former plugin will be chosen. Similarly, you can publish one instance for QGIS=1.0 and another one for QGIS =1.1 Just remember to give a higher version for the latter one and installer choose the highest one if the =1.1 requirement is fulfilled. Note that both files are named foo.zip, so you can't put them together to the main contributed repository, as they all are stored in one directory there. But you can use the suffix I mentioned in my previous mail: foo.zip containing the directory foo foo.beta.zip containing the same directory foo Oh, the main repository doesn't handle the 'experimental' tag yet, AFAIK? But I hope it will be implemented soon. Note that there are only two levels of stability: experimental or not. It has been discussed whether we need more and realized that just don't. Please remember that there are so many authors with different opinions and different willingness to keep metadata accurate ;) that I found keeping it as simple as possible reallyu essential :) ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [SPAM] RE: [Qgis-user] Public Repository for plugins...
Tuesday 16 of June 2009 15:18:37 Sampson, David napisał(a): For a community plugin repo I assume that multiple authors might be involved in the development of a plugin For the element... author_nameSomeone/author_name Can this be a comman separated value. sure I am thinking of automaticaly generating this from an AUTHORS.txt file Also, is there an e-mail optio we can add or Not yet, but is definitely essential! Sometimes it's really hard to contact the author, as email is not included even to source files. We can add a tag email or include emails to the author_name tag. The latter option is better for multiple authors as I think. So let's allow both solutions. Installer will both handle the email tag and parse everything looking like an email from the author_name. Of course this could be also an easy pray for spamers, so we need to find the best way to format email address. what about a URL to an AUTHORS file? The main blocker is free space in Installer window ;) If authors are ready to provide more info (screenshots, longer descriptions, changelogs), we can make Installer more verbose and implement a big browser for pretty formatted metadata. ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [SPAM] RE: [Qgis-user] Public Repository for plugins...
Tuesday 16 of June 2009 15:03:11 Sampson, David napisał(a): Just as I am going through a pseudo code exercise of release.py I see three cases. 1. Current and previous stable versions VERSION 2. A Beta version is is being tested an on its way to stable. BETA 3. An unstable snapshot of the development trunk ALPHA If we assume that most new feature development is done in the branches and merged to trunk, then trunk should not be all the harry and trashy. The branches would be way to unstable. This way then regular users can try unstable and beta version of the plugins wihtout needing to get into SVN carnage. For now I will call trunk snapshots BETA Just some thoughts. So do we want to have three levels? The present experimental tagging style is related to the fact that many authors just release either plugins considerable as stable, or just some concepts. But if we are going to develop more complicated plugins (and it seems we are), there is a reason to do more precise tagging, of course ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
RE: [SPAM] RE: [Qgis-user] Public Repository for plugins...
I don't want to speak on behalf of the community, I just came across what I figured would work for the central repo and kinda matches typical; open source projects that facilitate the three options. Cheers -Original Message- From: qgis-user-boun...@lists.osgeo.org [mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of Borys Jurgiel Sent: Tuesday, June 16, 2009 09:44 To: qgis-user@lists.osgeo.org Subject: Re: [SPAM] RE: [Qgis-user] Public Repository for plugins... Tuesday 16 of June 2009 15:03:11 Sampson, David napisał(a): Just as I am going through a pseudo code exercise of release.py I see three cases. 1. Current and previous stable versions VERSION 2. A Beta version is is being tested an on its way to stable. BETA 3. An unstable snapshot of the development trunk ALPHA If we assume that most new feature development is done in the branches and merged to trunk, then trunk should not be all the harry and trashy. The branches would be way to unstable. This way then regular users can try unstable and beta version of the plugins wihtout needing to get into SVN carnage. For now I will call trunk snapshots BETA Just some thoughts. So do we want to have three levels? The present experimental tagging style is related to the fact that many authors just release either plugins considerable as stable, or just some concepts. But if we are going to develop more complicated plugins (and it seems we are), there is a reason to do more precise tagging, of course ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Public Repository for plugins...
Monday 08 of June 2009 22:42:34 Dane Springmeyer napisał(a): Funny - how is it that there are only two 'official plugins'? Yes - nobody is keen to form a High Committee and evaluate plugins... :( ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Public Repository for plugins...
Borys Jurgiel wrote: Monday 08 of June 2009 22:42:34 Dane Springmeyer napisał(a): Funny - how is it that there are only two 'official plugins'? Yes - nobody is keen to form a High Committee and evaluate plugins... :( I don't think too many people have asked, besides that it seems that plugins that are really good end up in the core code most of the time and don't exist as separate plugins for long. Alex ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Public Repository for plugins...
Dane Springmeyer ha scritto: I would vote for SVN, because it lends itself to the multiple directory, many projects approach, while mercurial is specifically designed to house only a single code project. I would avoid multiplying sites and services: why not just adding a branch to main svn, or adding one project (qgis-plugins) to the existing osgeo infrastructure? All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Public Repository for plugins...
Paolo Cavallini wrote: Dane Springmeyer ha scritto: I would vote for SVN, because it lends itself to the multiple directory, many projects approach, while mercurial is specifically designed to house only a single code project. I would avoid multiplying sites and services: why not just adding a branch to main svn, or adding one project (qgis-plugins) to the existing osgeo infrastructure? All the best. I agree a new osgeo svn qgis-plugins might be the best approach. We probably don't want to make it a branch in the main svn as that would require opening access to the svn to a large number of potential accidents from new contributors. It would also be important to highlight that these will still mostly be contributed not official plugins. The most difficult part would be handling user registration, and management. But if we are good with allowing just about anyone few questions asked then it would work. If we need more infrastructure than that to allow people to assign and create teams etc and existing platform might suit the task better. Alex ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Public Repository for plugins...
Sampson, David wrote: Is there a co-ordinated effort o house multiple QGIS plugins in the same place? I am thinking specifically of python plugins that deal with OGC type services. Sourceforge is a classic option There is also http://code.google.com/opensource/ I am thinking one central place for people that don't want the overhead of housing their own code. The thought would be something like the following in the repo Repo == Plugin I== trunk branches tags Plugin II == trunk branches tags Basicaly housing a bunch of plugins in one place in one repo and different people are responsible for their different plugins and we all follow the proper way to package and distribute to the python plugin loader. Thoughts? We've discussed it briefly previously and I believe Gary was looking into how to do this so it would be integrated with the distribution site http://pyqgis.org/ Although that appears to be down at the moment, it's where the Official and Contributed Plugins are hosted from. As I pointed out in a previous thread on this the model you wrote is basically like trac-hacks.org, and feasible. There is some question as to whether we should go with a DVCS to allow for more flexibility in merging and trading pieces. It appears that some plugin devs prefer Git or Mercurial over svn for this stuff. Overall though I agree we need a central hub for plugin development to make it easier to manage the Official ones and allow champions to easily pickup where someone else left off. Alex ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
RE: [Qgis-user] Public Repository for plugins...
Maybe those that are interested can have a little thread and come up with a temp solutions while the ducks line up... I would propose sourceforge as that is what I know and I already help admin a project on sourceforge. I would say if we can get three plugin groups working together that is a good start. Any takers? Cheers -Original Message- From: qgis-user-boun...@lists.osgeo.org [mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of Alex Mandel Sent: Monday, June 08, 2009 15:41 To: qgis-user@lists.osgeo.org Subject: Re: [Qgis-user] Public Repository for plugins... Sampson, David wrote: Is there a co-ordinated effort o house multiple QGIS plugins in the same place? I am thinking specifically of python plugins that deal with OGC type services. Sourceforge is a classic option There is also http://code.google.com/opensource/ I am thinking one central place for people that don't want the overhead of housing their own code. The thought would be something like the following in the repo Repo == Plugin I== trunk branches tags Plugin II == trunk branches tags Basicaly housing a bunch of plugins in one place in one repo and different people are responsible for their different plugins and we all follow the proper way to package and distribute to the python plugin loader. Thoughts? We've discussed it briefly previously and I believe Gary was looking into how to do this so it would be integrated with the distribution site http://pyqgis.org/ Although that appears to be down at the moment, it's where the Official and Contributed Plugins are hosted from. As I pointed out in a previous thread on this the model you wrote is basically like trac-hacks.org, and feasible. There is some question as to whether we should go with a DVCS to allow for more flexibility in merging and trading pieces. It appears that some plugin devs prefer Git or Mercurial over svn for this stuff. Overall though I agree we need a central hub for plugin development to make it easier to manage the Official ones and allow champions to easily pickup where someone else left off. Alex ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-user mailing list Qgis-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user
