[Qgis-developer] The new QGIS plugin repo

Carson Farmer carson.farmer at gmail.com
Mon Jun 28 09:02:11 EDT 2010


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 <borysiasty at aster.pl> 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
> Qgis-developer at lists.osgeo.org
> 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/


More information about the Qgis-developer mailing list