Re: [Qgis-user] Public Repository for plugins...

[Borys Jurgiel]

Thursday 18 of June 2009 21:51:22 Volkan Kepoglu napisał(a):
> 
> 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.

I'll think about it. For now, you can mark it in the name or version number.
Or, as a user, you can disable and enable the checkbox. All available metadata 
is cached, so it won't cause any annoying refreshing.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Public Repository for plugins...

[Volkan Kepoglu]

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.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://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.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: [SPAM] RE: [Qgis-user] Public Repository for plugins...

[Sampson, David]

 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: [SPAM] RE: [Qgis-user] Public Repository for plugins...

[Borys Jurgiel]

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

[Borys Jurgiel]

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... Someone
> 
> 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  or include emails to the  tag. The latter 
option is better for multiple authors as I think. 

So let's allow both solutions. Installer will both handle the  tag and 
parse everything looking like an email from the .

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: [Qgis-user] Public Repository for plugins...

[Sampson, David]

 
For a community plugin repo I assume that multiple authors might be involved in 
the development of a plugin

For the element... Someone

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:
> 
>   
> Some description
> http://foo
> 1.0
> foo.zip
> Someone
> http://some_url/some_dir/foo.zip
>   
> 
>   
> Some description
> http://foo
> 1.0
> foo.zip
> Someone
> http://some_url/another_dir/foo.zip
> true
>   
> 
> Note that there are two plugins foo.zip. The latter one has 
> higher version number, but is marked with the optional tag 
> . 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: 
>  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...

[Sampson, David]

 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:
> 
>   
> Some description
> http://foo
> 1.0
> foo.zip
> Someone
> http://some_url/some_dir/foo.zip
>   
> 
>   
> Some description
> http://foo
> 1.0
> foo.zip
> Someone
> http://some_url/another_dir/foo.zip
> true
>   
> 
> Note that there are two plugins foo.zip. The latter one has 
> higher version number, but is marked with the optional tag 
> . 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: 
>  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...

[Sampson, David]

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

[Borys Jurgiel]

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

[Volkan Kepoglu]

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

[Alex Mandel]

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

[Borys Jurgiel]

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]

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:

  
Some description
http://foo
1.0
foo.zip
Someone
http://some_url/some_dir/foo.zip
  

  
Some description
http://foo
1.0
foo.zip
Someone
http://some_url/another_dir/foo.zip
true
  

Note that there are two plugins foo.zip. The latter one has higher version 
number, but is marked with the optional tag . 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:  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

RE: [Qgis-user] Public Repository for plugins...

[Sampson, David]

Well Folks,

I took the liberty of going ahead and setting up a sourceforge project
to house multiple plugin projects.

Let me know if you want a chunk of the repo. The faster I relinquish
control the happier I will be :)


Hope this helps 

http://qgiscommunitypl.sourceforge.net/

cheers

> -Original Message-
> From: qgis-user-boun...@lists.osgeo.org 
> [mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of Paolo 
> Cavallini
> Sent: Tuesday, June 09, 2009 03:14
> To: t...@wildintellect.com
> Cc: qgis-user@lists.osgeo.org
> Subject: Re: [Qgis-user] Public Repository for plugins...
> 
> Alex Mandel ha scritto:
> 
> > The most difficult part would be handling user registration, and
> 
> http://trac-hacks.org/wiki/AccountManagerPlugin ?
> 
> 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
> 
___
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]

Alex Mandel ha scritto:

> The most difficult part would be handling user registration, and

http://trac-hacks.org/wiki/AccountManagerPlugin ?

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

[Alex Mandel]

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

[Paolo Cavallini]

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

[Dane Springmeyer]

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.



I think this is a great idea and free SVN hosting like google code  
would work well for this.




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/



Funny - how is it that there are only two 'official plugins'?

Although that appears to be down at the moment, it's where the  
Official

and Contributed Plugins are hosted from.



works for me


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.


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.




It appears that some plugin devs prefer Git
or Mercurial over svn for this stuff.



The only reason I use mercurial (http://bitbucket.org/springmeyer/quantumnik/ 
) is because for early development of unique projects I personally  
prefer to having ONE clear wiki for ONE clear project with ONE rss  
feed I can share with folks. (While I really enjoy using google code  
for a sandbox for lots of other stuff, like with http://code.google.com/p/mapnik-utils/.)


So, I would imagine that David's suggestion of a kind of group  
versioned code site (even though I may not use myself), would be best  
using Subversion.



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.



Someone create one!

Dane

___
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]

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

Re: [Qgis-user] Public Repository for plugins...

[Alex Mandel]

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