[Qgis-developer] Way forward: QGIS plugin repo, plugin Trac etc.
lists at linfiniti.com
Wed Nov 17 06:22:13 EST 2010
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.
>> 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.
> 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.
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
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
Irc: timlinux on #qgis at freenode.net
More information about the Qgis-developer