[Qgis-developer] Way forward: QGIS plugin repo, plugin Trac etc.

Tim Sutton lists at linfiniti.com
Wed Nov 17 07:05:45 EST 2010


On Tue, Nov 16, 2010 at 11:39 AM, Pirmin Kalberer <pi_ml at sourcepole.com> wrote:

> I would group the aspects in
> 1. Package repository + Package download website

Right lets call this 'the plugin portal' to be developed using django
+ git + github for issue tracking.

> 2. Plugin source code repository

Correct. Proposal from some is to provide an svn with liberal access
(anyone can get a committer account) with each user given write access
only to their project folder. Some in the discussion have suggested we
just skip this part an focus on 1 & 3. Using git instead of svn for
this part would also be fine though the concensus seemed to be that
people are more likely to be familiar with svn and that they can just
create github accounts if they want to use git.

> 3. Bug tracking + Plugin home pages

Right. Bug tracking seems to me to be where the main contention lies
(between trac or redmine). Personally I dont have a strong opinion
either way other than being familiar with trac and unfamiliar with

For plugin home pages - isnt this something that can be provided as
part of the plugin portal? Should be easy to do?

I think we need to just pick a set of technologies that a) offers the
best functionality as individual parts b) are easily integrated and c)
that will be most easily adapted to by plugin authors. I say 'just' in
my previous sentance though socially it seems difficult to actually
make the choice between such a mixed bag of technologies, so maybe it
should come down to 'he who is prepared to maintain it has the
strongest argument'. In which case since Alex is prepared to put in
the work on the insfrastructure side for the plugins versioning and
issue tracker we should just let him set something up and go with it.

For the qgis portal side I think everything is catered for with github
and we can just get on with it.



> Borys and Martin proposed a solution for point 1, developed with Django. They
> did not couple the package repository with the source code repository to let
> plugin developers choose their SCM.
> Tim's announcement includes the following solutions for these aspects:
> 1. Django application
> 2. One(?) Github repository
> 3. One(?) Trac instance
> In the discussion Alex is referring to, we came to this:
> 1. not discussed
> 2. OSGeo Git server
> 3. Redmine
> We didn't go deeper into point 2 and number 3 was not confirmed by Tim.
> I have absolutely no problems with Tim's solution and I'm sure he will clarify
> open points as soon as he arrives in South Africa.
> Regards
> Pirmin
> --
> Pirmin Kalberer
> Sourcepole  -  Linux & Open Source Solutions
> http://www.sourcepole.com
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net

More information about the Qgis-developer mailing list