QGIS plugin repo [was: Value Tool]

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

QGIS plugin repo [was: Value Tool]

pcav
Il 12/06/2010 21:03, Maxim Dubinin ha scritto:

> We also have number of important improvements for this plugin that we
> use in house and it would be interesting to have an update on its
> development status from the author.
>
> Maxim
>
> Вы писали 12 июня 2010 г., 13:48:13:
>
> JEF> I understand it's a 3rd party plugin, so we can't expect qgis
> JEF> developers to fix that. Nevertheless does anyone knows if the
> JEF> developer of this great tool is still on it or is it an abandoned
> JEF> project? If so, maybe it would be a good idea to think on a
> JEF> similar tool to be included on the next release. It's just that
> JEF> making raster analysis without this tool can be very frustrating...

Hi all.
This brings another, more general question: how are going to deal with plugins? We
have a number of them that, even if they're not official, are so useful and widely
used we cannot afford missing. It has already happened several times now (and many
more times will happen in the future) that someone can and wants to improve someone
else's plugin, provide a patch, or simply to notify a bug. I think a trac is a
necessity now.
So I'm suggesting to open a separate trac, e.g. https://trac.osgeo.org/qgis-addons/
Alternatively, this could be a separate branch of the current trunk.
I can provide a script that automatizes plugin package generation from svn (we're
using it for our Faunalia plugins since several months now).
The only additional work for the admins would therefore be to grant selective access
to the addons to interested devs, but that's not too bad (and I can help if nobody
else has the time to do it). Of course any additional help is warmly welcomed.
Please let me know your feelings about this proposal.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS plugin repo [was: Value Tool]

Alex Mandel-2
On 06/13/2010 10:19 AM, Paolo Cavallini wrote:

> Il 12/06/2010 21:03, Maxim Dubinin ha scritto:
>> We also have number of important improvements for this plugin that we
>> use in house and it would be interesting to have an update on its
>> development status from the author.
>>
>> Maxim
>>
>> Вы писали 12 июня 2010 г., 13:48:13:
>>
>> JEF> I understand it's a 3rd party plugin, so we can't expect qgis
>> JEF> developers to fix that. Nevertheless does anyone knows if the
>> JEF> developer of this great tool is still on it or is it an abandoned
>> JEF> project? If so, maybe it would be a good idea to think on a
>> JEF> similar tool to be included on the next release. It's just that
>> JEF> making raster analysis without this tool can be very frustrating...
>
> Hi all.
> This brings another, more general question: how are going to deal with plugins? We
> have a number of them that, even if they're not official, are so useful and widely
> used we cannot afford missing. It has already happened several times now (and many
> more times will happen in the future) that someone can and wants to improve someone
> else's plugin, provide a patch, or simply to notify a bug. I think a trac is a
> necessity now.
> So I'm suggesting to open a separate trac, e.g. https://trac.osgeo.org/qgis-addons/
> Alternatively, this could be a separate branch of the current trunk.
> I can provide a script that automatizes plugin package generation from svn (we're
> using it for our Faunalia plugins since several months now).
> The only additional work for the admins would therefore be to grant selective access
> to the addons to interested devs, but that's not too bad (and I can help if nobody
> else has the time to do it). Of course any additional help is warmly welcomed.
> Please let me know your feelings about this proposal.
> All the best.

I've brought this up several times in the past too. Something similar to
http://trac-hacks.org would be great, especially if we can integrate it
with pyqgis.org so that you could click through the web to release a new
version to the xml repos.

I'll look into options, that would allow plugin authors or qgis devs to
grant access to plugins in an easy manner (through the web).

Would it make sense to do something more similar to github/bitbucket
where anyone can branch anyone else's stuff there just needs to be
cooperation to merge back?

Thanks,
Alex


_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS plugin repo [was: Value Tool]

Borys Jurgiel-2
In reply to this post by pcav
> Hi all.
> This brings another, more general question: how are going to deal with
> plugins? We have a number of them that, even if they're not official, are
> so useful and widely used we cannot afford missing. It has already
> happened several times now (and many more times will happen in the future)
> that someone can and wants to improve someone else's plugin, provide a
> patch, or simply to notify a bug.

It happens quite often, so the svn could be really big convenience! Also a
possibility to assign "many to many" devs to plugins is often requested (now I
have to totally change the ownership of abandoned plugins). The third priority
is automatic zip packaging and metadata generation, as such human mistakes
happens every one month.

svn + the publishing script + trac seems to be the solution for all major
problems. It's simple, convenient, powerful and flexible. It doesn't break the
existing plugin system and opens a way to painlessly introduce new features
(as keywords, categories, screenshots) to all plugins at once by an admin. It
even allows to create automatic changelogs for plugins that don't contain
them. Trac support can be even implemented in the installer for easier bug
reporting. In one world - it's exactly what we need.

> The only additional work for the admins would therefore be to grant
> selective access to the addons to interested devs, but that's not too bad
> (and I can help if nobody else has the time to do it). Of course any
> additional help is warmly welcomed. Please let me know your feelings about
> this proposal.

No problem for me, it's much more convenient that the present juggling with
zip files :) It's a shame on me, that I still have no time for improving this
system.

There's also one more important question. In Vienna we talked about making the  
repository a proxy to another ones. The main reasons were:
- performance: only one http request for fetching all metadata
- safety: possibility to lock broken/malicious plugin
- quality: on-the-fly testing of the zip package and metadata consistency

Now, with the trac, I wonder if author's repositories are necessary at all?
What about asking all authors for moving all their public plugins to the main
svn? There will be still the possibility to add an external repo for e.g.
internal purposes, but there will be no list of known 3rd party repos any
more. What do you think?

B.



_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS plugin repo [was: Value Tool]

Borys Jurgiel-2
In reply to this post by Alex Mandel-2
> I've brought this up several times in the past too. Something similar to
> http://trac-hacks.org would be great, especially if we can integrate it
> with pyqgis.org so that you could click through the web to release a new
> version to the xml repos.

Of course, it should be integrated. But it must be disputed how to trigger the
release? Also, how to maintain multiple versions? E.g. one stable and one
development. Should they be maintained in separate directories? If so, a
synchronization tool would be nice... A lot of questions, but I believe
there's a good basis in the end :)

> I'll look into options, that would allow plugin authors or qgis devs to
> grant access to plugins in an easy manner (through the web).

It's essential :)

> Would it make sense to do something more similar to github/bitbucket
> where anyone can branch anyone else's stuff there just needs to be
> cooperation to merge back?

Won't it result with still growing number of branches? I think it's not
necessary, I prefer the previous idea. Witch svn, everyone can just send a
patch to the author.
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS plugin repo [was: Value Tool]

Alex Mandel-2
On 06/13/2010 03:02 PM, Borys Jurgiel wrote:

>> I've brought this up several times in the past too. Something similar to
>> http://trac-hacks.org would be great, especially if we can integrate it
>> with pyqgis.org so that you could click through the web to release a new
>> version to the xml repos.
>
> Of course, it should be integrated. But it must be disputed how to trigger the
> release? Also, how to maintain multiple versions? E.g. one stable and one
> development. Should they be maintained in separate directories? If so, a
> synchronization tool would be nice... A lot of questions, but I believe
> there's a good basis in the end :)
>
>> I'll look into options, that would allow plugin authors or qgis devs to
>> grant access to plugins in an easy manner (through the web).
>
> It's essential :)
>

I think I found the answer http://trac-hacks.org/wiki/SvnAuthzAdminPlugin

Alex

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS plugin repo [was: Value Tool]

pcav
Thanks for the replies, and the interest on my proposal. I think the issues are:

- separate trac, or a branch of the current one?
- administering users: the plugin http://trac-hacks.org/wiki/SvnAuthzAdminPlugin is
certainly useful, but the current administrator should decide which one is the most
convenient for him (BTW: who is managing SVN permissions now?)
- user permissions: I do not think we need a complex many-to-many relation between
authors and plugins (could be a nightmare to administer): I suggest we can trust our
authors (we are dealing with third-party plugins, after all), and grant permissions
to the whole qgis-addons tree; this will also make easier for all authors to give a
hand to other projects when needed
- how to release: our script make a new release for every commit for experimental;
when it's ready, we commit to the stable branch, and it get autoreleased; I think it
is simple and efficient (it can certainly be improved, though)
- svn or git: I vote for svn, so to keep the same structure for the whole of qgis; we
can move everything to git when needed, but keeping two different systems is
potentially confusing and discouraging
- main repo as proxy: +1 for me; let's remove additional repos, to be used as sandbox
only.

If we can solve the few above-mentioned questions, I think we can implement this
rather easily and quickly.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS plugin repo [was: Value Tool]

Alex Mandel-2
Paolo Cavallini wrote:
> Thanks for the replies, and the interest on my proposal. I think the issues are:
>
> - separate trac, or a branch of the current one?
Could be doable within the same trac but potentially confusing.
Advantage, bugs and tickets are all filed in one place - disadvantage,
same thing(Could be solved by better tags and filtering). If the svn is
2 repos then it would have to be 2 trac sites.
This might be safer for the core code, preventing accidental slips in
permission changes and accidental writes. Sanity would dicate that we
just make a new folder in the main svn called PluginRepo or something of
the sort.


> - administering users: the plugin http://trac-hacks.org/wiki/SvnAuthzAdminPlugin is
> certainly useful, but the current administrator should decide which one is the most
> convenient for him (BTW: who is managing SVN permissions now?)
Currently svn permissions are by web script that qgis admins have access
to - Tim, Gary for sure, possibly Otto, Macho, and ?
I would consider it clumsy for fine grained permissions by plugin but ok
for granting access to all plugins(see comments below)


> - user permissions: I do not think we need a complex many-to-many relation between
> authors and plugins (could be a nightmare to administer): I suggest we can trust our
> authors (we are dealing with third-party plugins, after all), and grant permissions
> to the whole qgis-addons tree; this will also make easier for all authors to give a
> hand to other projects when needed
I do think developers might want to be able to control a little bit of
what goes on, otherwise the main QGIS devs have to vet applications for
access, since a single bad allow could cause days of work to correct.
Also I know for some plugins in their early stages coordination with the
main author is extremly important. They are mini projects on their own,
especially complex plugins, it might be very frustrating to have new
people experimenting in your plugin without your knowledge.

I think a similar workflow, of become known, submit patches against
plugin, ask for permission is the better model. Both the maintainer of
the plugin and the QGIS devs could be the gatekeepers (ie need 1 of them
to grant permission).

Of Course the main QGIS devs will be given access so that they can grant
 access to new people if it ever appears abandoned.

Alternate - plugin development agreement before given access with the
understanding that you will ask the other devs on a plugin before making
changes. In this case it would be an all or none.

The key here is were trying to encourage collaboration but not create
unusable spaghetti.

> - how to release: our script make a new release for every commit for experimental;
> when it's ready, we commit to the stable branch, and it get autoreleased; I think it
> is simple and efficient (it can certainly be improved, though)
I've started working on a new plugin to package (make zips while
dropping things like .svn/.cvs files), we could use the same backend of
such a script with a form front end as a track plugin to allow for "New
Release" and "New Experimental Release" buttons.

Not all work happens in branches, I do bugfixing in my trunk sometimes
but I don't want to annoy the user with a new release 4 times in one
day, or before it's ready. It's an intentional decision to release a new
version.

> - svn or git: I vote for svn, so to keep the same structure for the whole of qgis; we
> can move everything to git when needed, but keeping two different systems is
> potentially confusing and discouraging
I vote svn, keep it simple

> - main repo as proxy: +1 for me; let's remove additional repos, to be used as sandbox
> only.
>
+1

> If we can solve the few above-mentioned questions, I think we can implement this
> rather easily and quickly.
> All the best.

Those are my thoughts...
Thanks,
Alex
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS plugin repo [was: Value Tool]

pcav
Il 14/06/2010 08:04, Alex Mandel ha scritto:
>> If we can solve the few above-mentioned questions, I think we can implement this
>> rather easily and quickly.
>> All the best.
>
> Those are my thoughts...

Any other comment? Can we proceed? If yes, I'm available for help.
BTW: joining repos seems important: today 2 or 3 3rd party repos were down, pretty
unconvenient.
All the best.

--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS plugin repo [was: Value Tool]

Borys Jurgiel-3
Dnia wtorek, 15 czerwca 2010 o 21:46:23 Paolo Cavallini napisał(a):

> Il 14/06/2010 08:04, Alex Mandel ha scritto:
> >> If we can solve the few above-mentioned questions, I think we can
> >> implement this rather easily and quickly.
> >> All the best.
> >
> > Those are my thoughts...
>
> Any other comment? Can we proceed? If yes, I'm available for help.
> BTW: joining repos seems important: today 2 or 3 3rd party repos were down,
> pretty unconvenient.
> All the best.

I'm extremely busy till June 25th, then I'll join the battle. Now I can only
update the installer before the string freeze 21st.

I think we can assume there are no objections to proceed :) There are only
three steps necessary now: the svn branch, the script and the manual trigger
for releasing. If we won't decide what to do with the privilege system, I can
manage them.

PS. Oh, and a manual for new devs, how to use svn...
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS plugin repo [was: Value Tool]

pcav
Il 15/06/2010 22:24, Borys Jurgiel ha scritto:

> I'm extremely busy till June 25th, then I'll join the battle. Now I can only
> update the installer before the string freeze 21st.
>
> I think we can assume there are no objections to proceed :) There are only
> three steps necessary now: the svn branch, the script and the manual trigger
> for releasing. If we won't decide what to do with the privilege system, I can
> manage them.

Great. So let's postpone it after the 25th. The main issue remaining is: separate svn
(always on osgeo, I hope) or a branch of the existing one?
Any thoughts?
As for permissions, I think it is good to have a permission master (Borys) and a
backup one (I can do that, if nobody else pops up).
Then we can set up an autopackaging (for experimental) + autoreleasing (for stable)
script, possibly based on what we're using now at Faunalia.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS plugin repo [was: Value Tool]

Alex Mandel-2
On 06/16/2010 10:34 AM, Paolo Cavallini wrote:

> Il 15/06/2010 22:24, Borys Jurgiel ha scritto:
>
>> I'm extremely busy till June 25th, then I'll join the battle. Now I can only
>> update the installer before the string freeze 21st.
>>
>> I think we can assume there are no objections to proceed :) There are only
>> three steps necessary now: the svn branch, the script and the manual trigger
>> for releasing. If we won't decide what to do with the privilege system, I can
>> manage them.
>
> Great. So let's postpone it after the 25th. The main issue remaining is: separate svn
> (always on osgeo, I hope) or a branch of the existing one?
> Any thoughts?
> As for permissions, I think it is good to have a permission master (Borys) and a
> backup one (I can do that, if nobody else pops up).
> Then we can set up an autopackaging (for experimental) + autoreleasing (for stable)
> script, possibly based on what we're using now at Faunalia.
> All the best.

I think we need the PSC to weigh in on what they would prefer in terms
of single or separate svn.

A permissions master, aka account approver would be ok. I think that's
how trac-hacks does it. We would need to some sort of plugin contributor
agreement I think and clear limits on what is/is not allowed (ie only
plugins with certain licensing would be permitted).

FYI, I also now have a test script that is working for bundling up a
directory of files with exclusion filters into a zip ready for upload.
I'm now working to turn it into a plugin, but the backend was designed
to work separate from the interface so it can easily be reused inside
trac. I'll be happy to post it as soon as we've got the repo going, in
the meantime if anyone wants to see the code let me know and I'll come
up with something.

Thanks,
Alex
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

The new QGIS plugin repo

Borys Jurgiel-3
In reply to this post by pcav
Hello PSC and other interested devs ;)

As we spoken a few days ago, we need the PSC decision for a few questions:

1. Do we go on at all? :)

2. Where to put the svn?
    a) branch of the existing qgis svn
    b) a separate svn on osgeo
    c) pyqgis.org (on the present server)
    d) on osgeo and park the pyqgis.org domain there
    e) yet another idea?

3. In case if pyqgis.org doesn't host the svn, where to put the output
repository.xml?
    a) on osgeo only
    b) on osgeo, and make a proxy on pyqgis.org
    c) the script on osgeo uploads all onto pyqgis.org

As soon as we find answers for the questions, we can go on:

- set up the repository, the script, triggers for releasing etc.
- replace the present repository.xml on pyqgis.org
- write a short svn tutorial for plugin authors
- request authors to move their plugins to the svn

From this point, qgis will use the new repository (if we keep the url on
pyqgis.org) and the author repositories will be redundant. When only most
authors move to the svn, I'll release the Installer update with shortened
plugin list. Necessary strings went to i18n files already.

Then will be time for better permission system (initially I can manage
permissions manually) and further improvements: keywords, categories, ratings
etc.

As we're freezing tomorrow, I think it makes no sense to adjust the Installer
to the new urls now and then start to implement all this stuff and try to
manage on the release time :)

B.
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: The new QGIS plugin repo

Borys Jurgiel-2
Dnia poniedziałek, 28 czerwca 2010 o 00:50:42 Carson Farmer napisał(a):

> > From this point, qgis will use the new repository (if we keep the url on
> > pyqgis.org) and the author repositories will be redundant. When only most
> > authors move to the svn, I'll release the Installer update with shortened
> > plugin list. Necessary strings went to i18n files already.
>
> Whoa! I guess I must have missed the discussion on this, but I'm not
> so sure that requiring all plugin authors to move their plugins to a
> central svn repository is a good idea. I think this will stifle the
> number of authors who actually release their plugins to the public, as
> many companies and organisations require that their derivative works
> remain on their own servers (often so they can easily keep track of
> downloads etc.). Is it too late to (re)open discussion on this topic
> (apologies for not following more closely to start with)?
>
> I would strongly oppose a complete move to a central svn repository. I
> understand the benefits to such a system, and for many authors this
> will be an ideal solution, however, I don't think it is ideal for all
> authors, and in the cases where it is not, I think it will become a
> barrier to entry. Will there be other options (i.e. something similar
> to the current setup, where plugin authors can host plugins on their
> own servers)? Perhaps I am confused, and this only applied to the
> official qgis repositories, and if so I apologise for the confusion.

You will still be able to add an external repository of course, however I'm
going to completely drop the "Add known 3rd party repositories" button. So
adding an external repository will be completely on your own and we will take
no responsibility on it. The reason is still growing number of problems:

- fetching repositories take more and more time
- it happens every few days that one of the repos is down
- it happens every two weeks that a zip package and/or metadata is broken (I
must admit this problem is bigger in the cental repository, but used to happen
everywhere)
- we have no possibility to immediately disable an invalid plugin until a
problem is fixed.

In Vienna we were talking about a proxy to author repositories, but seems
nobody has time to develop so huge application (It would need to unpack zip
packages to load the modules and rebuild metadata etc). So I like the Paolo's
idea to create a more friendly and powerful solution on the pyqgis.org to
attract more authors.

Anyway, we can just move the present central repositories to the svn solution
in the first step and then try to encourage owners of external repositories to
join. Even the first step would be a great improvement.

B.
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: The new QGIS plugin repo

Carson Farmer
Howdy Borys et al.

Will it be possible to control access to a particular plugin in the
central repository? In some cases, a developer (or a team of
developers) will prefer to limit changes/developments to their own
team (in some cases, this is a requirement of funding). I am pleased
to hear that external repositories will still be usable, wouldn't it
be relatively simple to have a web interface where authors could
submit their repository, and then have the installer simply add these
repos if the user wishes to add them? My concern with a completely
centralised system is that while we gain in control and (potentially)
stability, we lose in flexibility, and quite possibly usability. As it
is (fyi: I am not necessarily suggesting the current way is the way
things should be), it is quite easy for plugin authors to create a
plugin, create a repo, and host their plugins for all to access.
However, as you have mentioned, we (Borys) need to hard-code the repos
to the plugin installer for them to be added to the 'add 3rd party
repos' button, Well what about if the installer simply fetched a list
of 3rd party repos from the server, based on a list of submitted repos
via a web interface similar to the one for adding plugins to the
current repository? This alleviates the pressure on Borys and the rest
of the team in terms of keeping things up to date, and the repos that
are down will simply time-out, and if the repos have problems, their
plugins will simple not be available until those problems are fixed?
Perhaps I am over simplifying things here, but my concern is that we
will loose many valuable plugins simply because we are imposing
structure on plugin developers who may not want it (i.e. they might
already have their own code repository that they prefer using, or
indeed do not want to have to learn an additional tool such as svn).

I hope I'm not being a pain here, but I want to make sure that any
changes that are made, are only made if they significantly improve
both the user and developer experience.

Regards,

Carson

On 28 June 2010 10:51, Borys Jurgiel <[hidden email]> wrote:

> Dnia poniedziałek, 28 czerwca 2010 o 00:50:42 Carson Farmer napisał(a):
>> > From this point, qgis will use the new repository (if we keep the url on
>> > pyqgis.org) and the author repositories will be redundant. When only most
>> > authors move to the svn, I'll release the Installer update with shortened
>> > plugin list. Necessary strings went to i18n files already.
>>
>> Whoa! I guess I must have missed the discussion on this, but I'm not
>> so sure that requiring all plugin authors to move their plugins to a
>> central svn repository is a good idea. I think this will stifle the
>> number of authors who actually release their plugins to the public, as
>> many companies and organisations require that their derivative works
>> remain on their own servers (often so they can easily keep track of
>> downloads etc.). Is it too late to (re)open discussion on this topic
>> (apologies for not following more closely to start with)?
>>
>> I would strongly oppose a complete move to a central svn repository. I
>> understand the benefits to such a system, and for many authors this
>> will be an ideal solution, however, I don't think it is ideal for all
>> authors, and in the cases where it is not, I think it will become a
>> barrier to entry. Will there be other options (i.e. something similar
>> to the current setup, where plugin authors can host plugins on their
>> own servers)? Perhaps I am confused, and this only applied to the
>> official qgis repositories, and if so I apologise for the confusion.
>
> You will still be able to add an external repository of course, however I'm
> going to completely drop the "Add known 3rd party repositories" button. So
> adding an external repository will be completely on your own and we will take
> no responsibility on it. The reason is still growing number of problems:
>
> - fetching repositories take more and more time
> - it happens every few days that one of the repos is down
> - it happens every two weeks that a zip package and/or metadata is broken (I
> must admit this problem is bigger in the cental repository, but used to happen
> everywhere)
> - we have no possibility to immediately disable an invalid plugin until a
> problem is fixed.
>
> In Vienna we were talking about a proxy to author repositories, but seems
> nobody has time to develop so huge application (It would need to unpack zip
> packages to load the modules and rebuild metadata etc). So I like the Paolo's
> idea to create a more friendly and powerful solution on the pyqgis.org to
> attract more authors.
>
> Anyway, we can just move the present central repositories to the svn solution
> in the first step and then try to encourage owners of external repositories to
> join. Even the first step would be a great improvement.
>
> B.
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



--
Carson J. Q. Farmer
ISSP Doctoral Fellow
National Centre for Geocomputation
National University of Ireland, Maynooth,
http://www.carsonfarmer.com/
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: The new QGIS plugin repo

Barry Rowlingson
In reply to this post by Borys Jurgiel-2
On Mon, Jun 28, 2010 at 10:51 AM, Borys Jurgiel <[hidden email]> wrote:

> You will still be able to add an external repository of course, however I'm
> going to completely drop the "Add known 3rd party repositories" button. So
> adding an external repository will be completely on your own and we will take
> no responsibility on it.

 What would stop me writing an 'Add 3rd party repositories' plugin to
Qgis, and having that hosted in the main Qgis repositories?

 Eventually it might become such a useful add-on it could be folded
back into core Qgis... Wait, what?

Barry
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: The new QGIS plugin repo

Borys Jurgiel-2
In reply to this post by Carson Farmer
Dnia poniedziałek, 28 czerwca 2010 o 15:02:11 Carson Farmer napisał(a):
> Howdy Borys et al.
>
> Will it be possible to control access to a particular plugin in the
> central repository? In some cases, a developer (or a team of
> developers) will prefer to limit changes/developments to their own
> team (in some cases, this is a requirement of funding).

Of course! The plugin owner and repo admins would be allowed to grant and take
away the privileges. We can even think about separate disk space and webpage
for each author.

> I am pleased
> to hear that external repositories will still be usable, wouldn't it
> be relatively simple to have a web interface where authors could
> submit their repository, and then have the installer simply add these
> repos if the user wishes to add them? My concern with a completely
> centralised system is that while we gain in control and (potentially)
> stability, we lose in flexibility, and quite possibly usability. As it
> is (fyi: I am not necessarily suggesting the current way is the way
> things should be), it is quite easy for plugin authors to create a
> plugin, create a repo, and host their plugins for all to access.
> However, as you have mentioned, we (Borys) need to hard-code the repos
> to the plugin installer for them to be added to the 'add 3rd party
> repos' button, Well what about if the installer simply fetched a list
> of 3rd party repos from the server, based on a list of submitted repos
> via a web interface similar to the one for adding plugins to the
> current repository? This alleviates the pressure on Borys and the rest
> of the team in terms of keeping things up to date, and the repos that
> are down will simply time-out, and if the repos have problems, their
> plugins will simple not be available until those problems are fixed?

Do you suggest to manually block whole repository every time I discover that
one of its plugins contains a small mismatch in metadata (e.g. causing the
stubborn false upgradeable status)? It would affect users of other plugins...

Also it doesn't resolve connection problems. As far as I can hear it's quite
irritating for some users (me too) to wait for fetching all repos and kill
hanging connections.

I prefer our primary idea of proxying and automatic testing of each plugin,
but it seems to be an unnecessary complication. I'd prefer to spend this time
on building an author-friendly central repo and encourage authors to use it
rather than on building such weird proxy :) It would take weeks of writing
such application and will give relatively small profit.

All I want to do is to keep constrain some quality standards. The hand-made
xml metadata and zip packages are not acceptable. You don't see that every
week I send notices to authors of broken plugins - let's imagine what was if
I'd break both hands and stop to poke them ;-DDD

It was good when there was only a few repositories, but now it's too more.

> Perhaps I am over simplifying things here, but my concern is that we
> will loose many valuable plugins simply because we are imposing
> structure on plugin developers who may not want it (i.e. they might
> already have their own code repository that they prefer using, or
> indeed do not want to have to learn an additional tool such as svn).

I don't believe someone would prefer to fight against metadata instead of
simply use svn. There are many graphical clients, so commiting changes
requires one rightclick. Instead, the present solution makes you to:

1. remove .pyc files
2. make the zip package
3. upload the package
4. update the version number in repo.xml
5. restart qgis
6. install the plugin to test the package and metadata
7. [ restore your development environment if damaged in the previous step]

If you don't test plugins every time after commit, better don't confess ;p

The real problem is marketing. I understand someone can prefer to keep all
stuff in his domain... But instead, we can enable them to keep their
trademarks and url in the installer, right next to the plugin description.

Anyway, I've just closed my repository and move all plugins to the contributed
one :-)

> I hope I'm not being a pain here, but I want to make sure that any
> changes that are made, are only made if they significantly improve
> both the user and developer experience.

Sure! I'm glad to see a critical opinion in the end :)

B.
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: The new QGIS plugin repo

Borys Jurgiel-2
In reply to this post by Barry Rowlingson
Dnia poniedziałek, 28 czerwca 2010 o 15:23:06 Barry Rowlingson napisał(a):

> On Mon, Jun 28, 2010 at 10:51 AM, Borys Jurgiel <[hidden email]> wrote:
> > You will still be able to add an external repository of course, however
> > I'm going to completely drop the "Add known 3rd party repositories"
> > button. So adding an external repository will be completely on your own
> > and we will take no responsibility on it.
>
>  What would stop me writing an 'Add 3rd party repositories' plugin to
> Qgis, and having that hosted in the main Qgis repositories?
>
>  Eventually it might become such a useful add-on it could be folded
> back into core Qgis... Wait, what?

:)

What so painfull is in one-click automatic plugin publishing directly from
your filemanager/console? :-) With proper metadata and changelog.

B.
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: The new QGIS plugin repo

Borys Jurgiel-3
In reply to this post by Borys Jurgiel-2
> > Perhaps I am over simplifying things here, but my concern is that we
> > will loose many valuable plugins simply because we are imposing
> > structure on plugin developers who may not want it (i.e. they might
> > already have their own code repository that they prefer using, or
> > indeed do not want to have to learn an additional tool such as svn).

We can also ask all repo owners if they would be willing to move to such
convenient central repo. Hey, are you here, Owners? :)

We can start from converting the present central repo (what is needed anyway)
and then try just start to encourage them without any pressure.
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: The new QGIS plugin repo

Maxim Dubinin
BJ> We can also ask all repo owners if they would be willing to move to such
BJ> convenient central repo. Hey, are you here, Owners?

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.

Maxim

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


Вы писали 1 июля 2010 г., 12:25:00:

>> > Perhaps I am over simplifying things here, but my concern is that we
>> > will loose many valuable plugins simply because we are imposing
>> > structure on plugin developers who may not want it (i.e. they might
>> > already have their own code repository that they prefer using, or
>> > indeed do not want to have to learn an additional tool such as svn).

BJ> We can also ask all repo owners if they would be willing to move to such
BJ> convenient central repo. Hey, are you here, Owners?  

BJ> We can start from converting the present central repo (what is needed anyway)
BJ> and then try just start to encourage them without any pressure.
BJ> _______________________________________________
BJ> Qgis-developer mailing list
BJ> [hidden email]
BJ> http://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: The new QGIS plugin repo

Borys Jurgiel-2

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
123