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

[Martin Dobias]

On Wed, Nov 17, 2010 at 12:22 PM, Tim Sutton <lists at linfiniti.com> wrote:
> Hi
>
> 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.

Right - trac is a good option because users know it, developers know
it, some people even know how to administrate it :-) So unless other
bug tracking system comes with some features that we seriously need
and Trac does not have them, we should probably stick to it.


> 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.

Right, there are two separate things from my point of view: plugin
repository and ticket system for plugins. While we can choose from
various available bug tracking systems, the requirements for the
plugin repository are quite unique and I'm not aware of any existing
software that could be used for it.

I have updated the plugin repository wiki page and tried to dump as
much as possible from the ideas and requirements:
http://www.qgis.org/wiki/PluginRepository

>>>> #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.

My opinion is that we simply shouldn't provide a common svn/git
repository for plugin authors. Why try to provide source code hosting
for 3rd parties if there are lots of easily accessible free source
code hosting services? There is Google Project Hosting
(SVN/Mercurial), SourceForge (SVN/CVS/Git/Mercurial/Bazaar), BitBucket
(SVN/Mercurial), GitHub and Gitorious (Git) and many others. These
services allow users to create their code hosting in one minute and
what is most important - with no admin overhead for QGIS project. We
could just give the plugin authors some hints which hostings are the
best.

Additionally the free hostings usually provide bug tracking systems
and other services, so we could possibly even skip the part with
setting up a common bug tracking system for 3rd party plugins. Because
if a plugin author is not willing to use the common tracking system,
the number of tickets will increase without being ever resolved.

Regards
Martin