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

[Alex Mandel]

On 11/15/2010 01:23 PM, Borys Jurgiel wrote:
>> So change of mind from our discussion on IRC yesterday? Should Pirmin
>> and I still bother with the test install of Redmine?
> 
> Actually I'm still a bit confused and don't want to take one of the two sides 
> (mainly because I only looked briefly at the Redmine), but let's just write 
> down the disadvantages and threats of the two solutions.
> 
> Django:
> + the repository is easy to write
> ? can we connect a vcs as an integrated backend to the repo? (If no, let's try 
> to sketch the workflow with external ones - are all the authors granted to 
> upload the release to the repo or only the coordinator is, etc)
Not out of the box as far as I know, but nothing's impossible. (might be
faster to use something premade)
> ? can we handle existing osgeo accounts via ldap?
Should not be an issue for any of the options.
> ? can we write a trac plugin for syncronizing #tickets with release versions 
> only, or with revisions in the backend vcs too?
> ? any other thoughts... 
I think it would be easy to write a django app that pulls from an svn or
git specified by the user, zips up the files and posts the plugin for
download. The user managing a given plugin would just need to ensure the
right link to their source code.

What do you mean by "synchronizing" tickets? Any arbitrary version
numbers could exist in trac, are you thinking you want that to link to a
django site url? That sounds doable to me.

> 
> Redmine:
> ? I assume, all the trac and vcs system is OFTB. Am I right?
> ? What with the repo itself? Is the API sufficient for uploading and 
> downloading zips and downloading the metadata in easy-to-parse format? If not, 
> should it be written as a (redmine) plugin? Is there anybody keen to write it? 
> (in Ruby, as I think?)
> ? any other thoughts...
Entirely possible if someone is up for Ruby. Probably also entirely
possible as a TracPlugin which would be python.
> 
> I've probably missed many important points after the 5 unsleepy days and 
> nights.
> 

I was under the impression the choices were between:
Django Frontend for hosting releases of plugins / Trac+svn backend for
issues and code
VS
Django Frontend for hosting releases of plugins / Redmine+git backend
for issues and code

That way we only loosely couple the front and back which while more
complex is more flexible and allows for easier opt-in components. Also
means the front-end dev won't be held up by backend issues. If people
stick to naming conventions it should be easy to create an easy link to
jump from a given plugin on the Django site to it's page on the trac
site or it's issue summary.


>  
>> To be clear #2 above is where the code for the django site itself will
>> be hosted, not the source code of plugins.
> 
> exactly
> 
>> #3 isn't going to be kinda weird for people to report bugs to github
>> about things not working on the website, or do we expect to just funnel
>> email comments about it to the bug system ourselves.
> 
> Maybe better let's keep the repository bugtracking inside its trac. Do you see 
> any disadvantages (except the case whole application hangs or crashes)
> 

I just thought it was odd to send people to github for issues related to
a QGIS website. Where do we currently log website issues?


>> #6 I assume this SVN integrated with the New plugin bug trac site is ok?
>> Did you still want the ability to set permissions by folder on the svn
>> (this is doable).
> 
> I think the major problem is to grant permissions to create new folders (when 
> creating each new plugin). Is it doable?
Based on my research this is not an issue if we use the following Trac
macros and plugins. When a user fills out the form to register a new
plugin it creates the svn folder.
http://trac-hacks.org/wiki/NewHackMacro (requires slight customization)
Permission per folder can be done through the web, or it could be an
all/none based on if you've been added to the approved list.
http://trac-hacks.org/wiki/SvnAuthzAdminPlugin

Although my read of Tim's announcement was that he no longer cared if
there was folder level permissions on the svn for plugin development.

Thanks,
Alex