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

[Alex Mandel]

On 11/19/2010 04:43 PM, Martin Dobias wrote:
> Hi Alex
> 
> On Sat, Nov 20, 2010 at 12:44 AM, Alex Mandel
> <tech_dev at wildintellect.com> wrote:
>>
>> 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).
> 
> Picking a 3rd party hosting service seems like an option. Anyway there
> were such motions before, but did not really succeed:
> http://sourceforge.net/projects/qgiscommunitypl/
> 

The biggest con is that we can't use osgeo logins if it's 3rd party.
This to me is a big barrier to getting people using it. So picking a
place a bunch of us already use would be good. We could speculate more
about why that one didn't pan out (had forgotten about it) but I think
the important parts are that there needs to be some buy-in (which I feel
we have now that we've discussed the options), some ability for qgis
core devs to admin over it (for rescue purposes), and more visibility
like obvious linkage from qgis.org and in this case the new plugin site
that's being built.

My guess is a survey amongst current plugin and core devs would have
them pick github 1st and maybe googlecode next with
bitbucket/launchpad/sourceforge on the least favorite end.

I also think Paolo is really excited about a central place to report and
track issues. His team seems to do most of it right now and I see how
other users searching the internet could really benefit from knowing
where to look/getting them in search results. Then it just becomes a
cultural thing to convince devs to pay attention to it.

> 
>> 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 just have the impression that the plugin developers mostly will not
> use that service. As you say, lots of plugins don't have any
> versioning system (or just a private one) and maybe that's because the
> authors do not need it for their work - more than 90% of the plugins
> are one-man shows.
> 

I actually see this as a potential issue going forward as more and more
people rely on plugins to get stuff done and there is potential to
incorporate some plugins that offer central functionality into the core.
A Bus number of 1 is kinda scary and while they may be one man shows
that might be because it too much effort to solicit help (I've heard
this from some developers out there over the years, 'I didn't open up
the code or ask for collaboration because it was too much extra work').

Lack of version control is a little frightening too (Carson lost all his
original work on ftools at one point because he wasn't using version
control, I think he recovered from the already released code). My goal
is to better enable collaboration and encourage good open source
programming practices.

> In the new plugin repository we would like to keep track of plugin
> updates - so determining whether the plugin is dead should be simple.
> 
> Regards
> Martin

Example, someone files a ticket with a patch to fix a major bug(feature)
in a plugin. Said plugin appears to be dead. So someone else grabs the
patch, forks the code, applies the patch and releases the plugin update.

I'm open to trying github right now before we go and install stuff if we
can figure out how to group stuff. I get the feeling the issue tracking
won't be super central but it's really easy to try it 1st before we
start installing stuff on the servers.

Thanks,
Alex