[Qgis-developer] The new QGIS plugin repo

[Alex Mandel]

On 10/21/2010 01:32 PM, Pirmin Kalberer wrote:
> 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
> 

Maybe we need to re-ask, re-answer the questions:
Who is the site for?
What information should it contain?
How much control do plugin authors need over their plugin?

I see in the discussion 2 different sites:
G1. For plugin authors, and bug reporters
G2. For general qgis users

My opinion is that the site is for group 1 and that group 2 will still
search for and explore plugins via the QGIS plugin installer.
G1. This is something like trac-hacks, github etc where it's about
getting to the code and helping as easily as possible. If you're clients
aren't coders or into bug reporting (most people are not) then this site
isn't for them.
G2. This site would be like the mozilla add-ons, which really could be
derived from the metadata for each plugin and automatically generated
into some site, or intergrated into the QGIS main site. Theoretically
bug reporting could be redirected from here to a pre-filled form that
already fills in which plugin they are reporting on.

I do see that it would be nice to find a way to make bug reporting
easier for less technical people, but we have to remember that will also
increase the number of duplicate, user error, and erroneous bug reports.

The SCM discussion in my mind is backseat(not critical), and if we care
to really go down the road there are big lists of pros/cons to each
option. DVCS is not the panacea cure all for all projects.

I look forward to poking at Redmine with you in Denver.

Thanks,
Alex