Hi all,

+1

I suppose the plugin approver should check if all the sources are available in the source (if no code repository is available), e.g. ui files. It would be important for those who would make a fork of a (already not supported) plugin.
A minimal documentation in the source may be obligatory.

Zoltan

On Wed, 27 Aug 2014, Matthias Kuhn wrote:

I would also prefer to keep the entry barrier low.

I.e. if a hobby-programmer does not add these fields to his plugin but
will happily make (the missing bits) of the source code available on
request (GPL states on request IIRC) it should be possible for him to
just upload the plugin, but get warned that he could make people a lot
more happier if he would set these fields. I can imagine people
struggle with git, do bugtracking by email or on an internal tracker,
don't have a homepage... But still make good plugins which could
eventually evolve into projects with all these parts included. There
are a lot of other things people can fail at. And just make these
things hard requirement because they are easy to check does not feel
right for me.

I would also vote for the solution of having different repos (
recommended, bood, creepy )

Matthias
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to