[Qgis-developer] Way forward: QGIS plugin repo, plugin Trac etc.
tech_dev at wildintellect.com
Wed Nov 17 11:56:54 EST 2010
On 11/17/2010 03:22 AM, Tim Sutton wrote:
> On Tue, Nov 16, 2010 at 12:23 AM, Alex Mandel
> <tech_dev at wildintellect.com> wrote:
>> 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?
> In the discussion at the hackfest (following the irc discussion) we
> felt that using trac would be a lower threshold to cross - a number of
> us know it (as admins), as do the users. Personally I'm not averse to
> using redmin so playing around on a test instance would be nice) but I
> think we should set some kind of cut off date and make a decision -
> Paolo and others are getting frustrated trying to manage plugin issues
> so it would be nice to get something in place as soon as possible.
>>> 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.
>>> + 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.
>>> ? 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
>> I was under the impression the choices were between:
>> Django Frontend for hosting releases of plugins / Trac+svn backend for
>> issues and code
>> 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.
>>>> #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)
> Ok I think Pirmin broke it down better than I in his follow up post,
> but lets try to separate discussion about the management of the
> codebase for the qgis-django project which among other things will
> provide the new plugin portal, from the plugins themselves. In the
> case of qgis-django portal, the suggestion was to completely manage it
> using github infrastructure.
>> 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).
> Yes the idea was that each plugin author would be given a folder that
> only they (or team members) could write to. Its an admin overhead (for
> you?) but would be the idea - liberal access so that anyone can have
> an svn write account but they can only write to their own dir.
Thanks for the clarification. By all means please set a date for the end
of the Redmine test. Note, the only reason we are trying Redmine is
because it's more likely to allow for web based creation of multiple git
repos, one per plugin which would easily take care of the permission issues.
I would like to hold off on setting up trac/svn for plugin-dev until we
are sure that Redmine/git is not what we want or doesn't work the way we
More information about the Qgis-developer