[Qgis-developer] The new QGIS plugin repo

[Carson Farmer]

> Do you suggest to manually block whole repository every time I discover that
> one of its plugins contains a small mismatch in metadata (e.g. causing the
> stubborn false upgradeable status)? It would affect users of other plugins...
Certainly not! In fact, I would suggest that you not worry about this
at all! I'm surprised to hear that you are emailing plugin authors so
frequently (especially if they aren't plugins from the official
repos). The user knows when they add the 3rd party repositories that
they are adding repos not maintained by the QGIS core development
team, so if one or two plugins say they've upgraded, but the metadeta
isn't quite right, that's a problem with the plugin author, and not
the QGIS folks. They should also expect some hiccups, after all,
that's probably why the plugin is in a separate repository anyway!?
The same is try for other plugin-based software... you simply don't
have the time to do the work of the authors!

> Also it doesn't resolve connection problems. As far as I can hear it's quite
> irritating for some users (me too) to wait for fetching all repos and kill
> hanging connections.
Couldn't this be solved by adding a simple timeout to the requests? I
know Qt Http etc has facilities for this built-in?

> I prefer our primary idea of proxying and automatic testing of each plugin,
> but it seems to be an unnecessary complication. I'd prefer to spend this time
> on building an author-friendly central repo and encourage authors to use it
> rather than on building such weird proxy :) It would take weeks of writing
> such application and will give relatively small profit.
I also like the idea of proxying, and I don't actually think it would
be as complicated as one might think (though I'm not an expert on
anything web-based really!). The other obvious option would be to
encourage authors to submit their plugins to the contributed
repository?

> All I want to do is to keep constrain some quality standards. The hand-made
> xml metadata and zip packages are not acceptable. You don't see that every
> week I send notices to authors of broken plugins - let's imagine what was if
> I'd break both hands and stop to poke them ;-DDD
Again, I'm surprised that you are doing this. I wouldn't think that
this is your responsibility at all! 3rd party repository authors
should be maintaining their own repositories, and if problems occur
(site down, etc.) then their connections will simply time-out, and
users won't be able to download their plugins. As for the hand-made
xml data: one solution would be to create a very simple python plugin
that parses their __init__.py file and extracts the relevant info
correctly.

I'd also like to suggest that the 'add 3rd party repos' button should
simply fetch a list of 3rd party repositories from the QGIS server
(some sort of list created by an online submission system). That way
there is no hard-coding of repos by Borys, and it's fair for all
authors. We can certainly have a few different lists (i.e. well tested
repos, experimental repos, and untested repos). And as more people use
the plugins from a particular repo, the repo can be moved up the
hierarchy. Obviously this type of a system would lend itself well to
eventually adding the facilities for users to rate plugins etc.

Maybe this is simply too much work at this stage, but I'd like us to
also consider other options...

Carson

-- 
Carson J. Q. Farmer
ISSP Doctoral Fellow
National Centre for Geocomputation
National University of Ireland, Maynooth,
http://www.carsonfarmer.com/