[Qgis-developer] QGIS plugin repo [was: Value Tool]

[Alex Mandel]

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