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