Hi On Tue, Nov 16, 2010 at 11:39 AM, Pirmin Kalberer <pi...@sourcepole.com> wrote:
-----8<-----snip------------------------------ > > 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 redmine. 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. Regards Tim > 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@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 ============================================== _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
