[Qgis-developer] The new QGIS plugin repo

[Pirmin Kalberer]

Am Donnerstag, 21. Oktober 2010, um 18.52:26 schrieb Alex Mandel:
> On 10/21/2010 01:39 AM, Pirmin Kalberer wrote:
> > Am Donnerstag, 21. Oktober 2010, um 10.20:01 schrieb Paolo Cavallini:
> >> Il 21/10/2010 10:08, Pirmin Kalberer ha scritto:
> >>> My proposal would be to start with a github account as a central SCM
> >>> for QGIS plugins. Similar to http://github.com/grails-plugins
> >>> (http://grails.org/plugin/home) e.g. Write access can then still be
> >>> granted per-plugin.
> >>> Having Redmine would give the advantage of having sub-projects.
> >>> Organizing plugins as sub-projects means, that each plugin has their
> >>> own trac-like site but tickets are also collected on master-project
> >>> level (e.g. qgis-plugins).
> >> 
> >> Redmine looks wonderful, thanks for the review.
> >> One thing that worries me is: changing from the current structure for
> >> bug reports, committing etc. to a new one could discourage develpers
> >> and users alike (remember, most people are lazy).
> > 
> > I'm a lazy developer, too ;-) But do we only want to attract grey-haired
> > GIS experts with long time CVS (you remember?) experience? In about two
> > years from now you will have to explain people how this non-distributed
> > SCM called SVN is working ;-)
> > 
> >> Other issue: what should be installed on OSGeo servers? I think we have
> >> some limitations there.
> > 
> > AFAIK we have virtual machines there. I would volunteer in setting up a
> > Redmine instance using the OSGeo LDAP logins. In our company we migrated
> > all Trac instances to one Redmine installation more than two years ago.
> > 
> > 
> > Pirmin
> 
> I'm not opposed to trying Redmine, but I do like the simplicity of
> http://trac-hacks.org/
> Each plugin gets one wiki page(more if they need) and one folder in the
> svn, really simple and straightforward. No real need for elaborate sites
> per plugin.
> 

Hi Alex,

It was not my intension to promote a Trac alternative. For me, the main 
question is still the SCM organisation. Personally, I don't want to give away 
the control of all our plugin source code. But having centralized access to 
the sources and a bug tracker is a benefit for all.
Trac is still a good tool for developers. Right now, QGIS is using it as a bug 
tracking tool and source code viewer.
The plugin repo is also an end user site, where QGIS users can find information 
about plugins. But when I show a trac page like http://trac-hacks.org/ to one 
of my customers, they instinctively know, that they're looking at a page for 
hackers (not only from the name).
Redmine is also inspired by Sourceforge, which fits quite well for a plugin 
ecosystem. The sub-project organisation would help that end user bug reports 
go to the right place without loosing the overview over all plugins. With its 
internationalization support it could also replace other QGIS portals in a 
long term. But like Trac it's far away from sites like addons.mozilla.org, 
which I think is out of reach for now. An automatically generated nice link 
page on the QGIS homepage or wiki could be good start.

> I'm also unconcerned about SVN going away any time soon, or trac for
> that matter: both are well used/known. I would feel more comfortable if
> more than one QGIS web admin knows Redmine well, since we know trac is
> well understood by OSGeo Admins.
> 
> QGIS has it's own VM on the OSGeo machines, so anything the PSC is
> willing to try is fair game. There's also the adhoc VM for more
> experimental stuff.

No doubt that SVN will reach the age of CVS. But a new generation of SCM  
systems is here and sooner or later also the FOSSGIS world will adapt it 
(http://github.com/openlayers/).
In case the QGIS devs vote for setting up setup a Redmine instance, I would 
certainly instruct other QGIS admins in Wroclaw. I will also attend the next 
FOSS4G in Denver, where I can show it other interested OSGEO admins....

Regards
Pirmin

-- 
Pirmin Kalberer
Sourcepole  -  Linux & Open Source Solutions
http://www.sourcepole.com