[Qgis-developer] plugins
Tim Sutton
tim at linfiniti.com
Mon Jul 7 18:54:42 EDT 2008
Hi Borys
2008/7/7 Borys Jurgiel <borys at wolf.most.org.pl>:
> I asked generally about my view of clearing the model of plugin developing,
> publishing and managing.
>
>> Ideas for managing versions you mean? Or for installing plugins
>> directly from the plugin manager? For the former I'm not sure what the
>> solution is
>
> It's the bigger trouble. Now the solution is a set of built-in workarounds,
> upgradeable with the whole Installer. After we move the Installer to
> the "permanent" plugin directory (and lose the upgradeability) I hope most of
> plugin authors will have it istalled and just see the possible errors.
> Furthermore, we can try to inform plugins developers, that from now proper
> plugin metadata will be much more important.
>
> However, sometimes someone may not test it accurately, so some rapid response
> force will be required. I see 2 solutions:
>
> 1) The official repository admin(s) - a men to badger distracted authors
> and/or correct the repository entries. Maybe it's not so stupid as it sounds.
> I think we should divide the repository into two parts: open unofficial and
> moderated official. In this case some mechanism to estimate the quality of
> particular plugins and move them from the unofficial to the official
> repository will be needed anyway.
>
> 2) The installer should have a posibility to use a upgradeable plugin with
> workaround functions. I mean just a small upgradeable plugin only for use by
> the Installer (and even ignored by the Plugin Manager). This solution isn't
> too smart, so it would be reserved only for extreme and temporary cases.
If I understand the issues correctly, my envisaged scenario would be:
- QGIS ships with 1 or more python plugins which are installed to a
read only location
- if an upgrade becomes available, the upgrade is installed into the
users ~/.qgis/etc dir
- user local installed plugins should mask out read only system plugins
- we should definately have an 'official' and an 'unoficial' repo distinction
- in order for plugins to be 'official' they should be:
* peer reviewed (or the authore at least vetted)
* signed using pgp or similar scheme
* use an appropriate license
- in order for a user to install an unofficial plugin there should be
a big red warning stating the potential security repurcussions of the
action they are about to take.
I think authors must be willing to demonstrate that they have paid due
dilligence before we act as an enabler for distributing their
software.
Regards
Tim
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
--
Tim Sutton
QGIS Project Steering Committee Member - Release Manager
Visit http://qgis.org for a great open source GIS
openModeller Desktop Developer
Visit http://openModeller.sf.net for a great open source ecological
niche modelling tool
Home Page: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
More information about the Qgis-developer
mailing list