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

[Alex Mandel]

On 11/19/2010 03:00 PM, Martin Dobias wrote:
> 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

I feel that a central option would help new plugin authors and authors
who want collaborate on plugins. I've created a sourceforge site for my
plugins in the past and attracted zero developers and only had a handful
of bugs put into my trac. Aside from that, a central place lets us
easily adopt abandoned plugins, and to give 1 place for reporting bugs
which in theory would improve the reporting and tracking of fixes.

I don't think we have to host it, but if we don't I would like to see us
pick one of the 3rd party hosting services and create a collaborative
collective under which people list their plugins(a qgis group).

A large number of plugins right now aren't even under version control
and even fewer of them have public tickets systems. So when I go to hack
on a plugin(that isn't mine) I never know if I have the latest code or
if it's been fixed and I don't expect an update to the release for every
little fix. I also have no idea if it's still under development, or
abandoned in favor of something else, merged into another plugin, etc.

I actually see a bug tracker also serving as a quality check. If like
you say a lot of bugs get filed for a plugin but never get solved, it
gives us the opportunity to ask if the plugin is dead, and if so to
change it's xml so users realize it's no longer being developed. Or to
calculate some measure of the plugins likelihood to work. It's also an
opt in thing, a plugin won't automatically be in the list of things to
report against.

As for the Trac vs. Redmine thing, yes we are specifically looking at
Redmine in the hopes that it can provide a feature that we don't think
Trac is capable of(easily) which is out of the box support for multiple
GIT repos.

Thanks,
Alex