On 04/20/2014 02:48 AM, Ricardo Filipe Soares Garcia da wrote:
> Hi list
>
> hub.qgis.org seems to be broken for people who want to use it as a
> repository for plugin's source code.
>
> I'm having problems with it since almost a year:
>
> http://osgeo-org.1560.x6.nabble.com/using-hub-qgis-org-git-repository-td5057063.html
>
> and there are also several tickets related to it:
>
> http://hub.qgis.org/issues/9741
> http://hub.qgis.org/issues/5969
> http://hub.qgis.org/issues/4890
>
> Currently there isn't even a way to manage SSH keys on the GUI, so it is
> impossible to use it as a source code repository.
>
> What is the word on this? Is hub.qgis.org no longer the preferred place to
> store plugin's source code?
>
You are correct, SSH key management broke (the redmine plugin for it). I
asked the maintainer, and the short answer is it was intentionally
removed because it was causing problems. Unless someone else can figure
out what's wrong with it, or replace it with something that works it
will never be fixed. Current system is based on redmine_gitosis, which
is no longer maintained. An alternative is redmine_gitolite, but that
requires work to move repos from gitosis to gitolite (can all be done by
server admin). A slightly more complicated move would be to upgrade
Redmine or migrate to it's fork Chili-project in addition to switching
to gitolite. I went this way on my own server years ago when it was
clear that combo is more popular and maintained.
The plugin documentation has not been updated to reflect that this
prevents uploading of source to hub. So yes, the unofficial
recommendation is external hosting of code. Alternative hosting
suggested includes any of the free vcs hosting out there: bitbucket,
google code, github, sourceforge, etc...
The bigger question for the whole developer community, if we're not
hosting code on hub anymore should we transition to hosting tickets
somewhere/something else?
The original intent of hub, and reason Redmine was picked, was to be
able to put multiple project trackers all in one spot. This enables
users to not have to guess or track down where an issue tracker for a
plugin can be found. It also means the whole community can easily see
when a particular plugin author is being completely unresponsive, and
the community can turn it over to adoptive devs.
One option I've done a little research on would be to move tickets to a
django based issue tracker and integrate it directly with the plugins
pages. We clearly don't have a strong set of Ruby sys admins so anything
python related might be easier to maintain. There's even a fork of Trac
called Bloodhound, either of which now supposedly do multi-project.
Some will suggest we move everything to github. My personal opinion is
that the github issue tracker is still quite inadequate for the
complexity of QGIS and it would force users to a 3rd party service which
they may or may not want to use. I can elaborate on my dissent if this
option starts to gain traction.
Thanks,
Alex
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
