[QGIS-Developer] Find unmaintained plugins

Stefan Keller sfkeller at gmail.com
Mon Feb 4 12:12:56 PST 2019


Hi,

Am Mo., 4. Feb. 2019 um 17:07 Uhr schrieb Thomas Baumann <
rdbath.regiodata at gmail.com>:

> But at the same time you have to see that buggy unmaintained plugins can
> cause a lot of frustration to users.
> I have made the experience that problems caused by such plugins are also
> actually very bad for the reputation of qgis.
>

I also see a need to inform users about buggy or not-working plugins.
Obviously the votes are not having this effect (since they only increase?).

But "maintained" does not mean "bug-free"  - as you all know e.g. from
commercial SW ;-).
And open source SW dev and maintenance in ones leisure time does not get
better when you get an flaq "unmaintained" on your plugin.

I'm thinking along the line to allow comments in the repo
http://plugins.qgis.org (always with mandatory info about version of
plugin, OS, etc.).
And in almost any  case, we need more maintainer (sic!) efforts to maintain
the plugin repo.

:Stefan

Am Mo., 4. Feb. 2019 um 17:07 Uhr schrieb Thomas Baumann <
rdbath.regiodata at gmail.com>:

> Hi,
> I can understand concerns about not wanting to discourage maintainers.
>
> But at the same time you have to see that buggy unmaintained plugins can
> cause a lot of frustration to users.
> I have made the experience that problems caused by such plugins are also
> actually very bad for the reputation of qgis.
> (Because most of the users (and the deciders in a company) won't
> differentiate between qgis "core" and the plugins which are distributed
> over the official(!) repository. From their point of view qgis is just
> buggy.)
>
> I think it's just fair to inform the user if a plugin is still maintained
> or not and to be honest I don't quite understand why it should be too hard
> to click on a confirmation-link once a year to prove that you still
> maintain a plugin.
>
> If the maintainer does not want to respond or does not find the time to
> click the link than I guess it just reflects the fact that the plugin isn't
> maintained by this person anymore.
>
>
> For qgis 2.18 there were more than 800 plugins in the official repository
> and I guess that in some years there could be even more plugins available
> for qgis 3.
>
> I think it will be hard to keep qgis3 stable and performant if buggy
> unmaintained plugins won't be sorted out or at least marked as unmaintained.
>
> Regards,
> Thomas
>
>
>
>
>
>
>
>
> Am Mo., 4. Feb. 2019, 15:25 hat Tim Sutton <tim at kartoza.com> geschrieben:
>
>> Hi
>>
>>
>> On 04 Feb 2019, at 00:30, Nyall Dawson <nyall.dawson at gmail.com> wrote:
>>
>> On Mon, 4 Feb 2019 at 00:57, Matthias Kuhn <matthias at opengis.ch> wrote:
>>
>>
>> Hi Paolo
>>
>> On 2/3/19 1:39 PM, Paolo Cavallini wrote:
>>
>> Hi Matthias,
>>
>> On 03/02/19 10:17, Matthias Kuhn wrote:
>>
>> Marking a plugin as "unmaintained" or "deprecated" is a heavy action
>> which may discourage developers and make even useful plugins disappear.
>>
>>
>> deprecated yes, unmaintained not necessarily. We could just let the user
>> know, perhaps suggesting a way to solve this, without removing them for
>> the list of available plugins (just like the Featured tag).
>>
>>
>> Then I misunderstood the goal of this proposal, sorry.
>>
>> I was imagining myself looking through a plugin list of a software of
>> which I am an ordinary user and seeing a plugin tagged as
>> "unmaintained". This would make me think it's unreliable, outdated and
>> unstable and hence not recommended.
>>
>>
>> I think this actually IS the intention here.
>>
>> But, as you've pointed out, no activity =/= unmaintained, as sometimes
>> no activity just means bug free and feature complete. In this case I
>> think it's fine to require developers to respond to a quick "is this
>> still maintained" survey in order to avoid the flag.
>>
>>
>> And sometimes even if the plugin is unmaintained it is still useful to
>> lots of people (even if it has a few known bugs)…..
>>
>> I’m not sure if flagging plugins as unmaintained is always so nice.. I
>> would favour an approach where we could just list plugins in the plugin
>> manager based on the date of their last release, most recent first so that
>> you can see old versus new
>>
>> Definitely -1 here on removing plugins that are orphaned unless they are
>> part of a security / data integrity risk. Many people may have built up
>> specific workflows around the existence of a particular plugin or two and
>> there is no need to break this for people even if the plugin is orphaned…
>>
>> Regards
>>
>> Tim
>>
>>
>>
>>>>
>>
>>
>>
>>
>>
>>
>> *Tim Sutton*
>>
>> *Co-founder:* Kartoza
>> *Ex Project chair:* QGIS.org
>>
>> Visit http://kartoza.com to find out about open source:
>>
>> Desktop GIS programming services
>> Geospatial web development
>> GIS Training
>> Consulting Services
>>
>> *Skype*: timlinux
>> *IRC:* timlinux on #qgis at freenode.net
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20190204/a656cf17/attachment.html>


More information about the QGIS-Developer mailing list