[Geany-Devel] Geany-Plugins rework -- RFC

[Thomas Martitz]

Am 21.11.2015 um 14:42 schrieb Frank Lanitz:
> Hi folks,
>
> Since a few releases I'm experiencing some not optimal way of
> development which is surely caused by the long history we already have
> on g-p as well as by the many people around luckily contributing to the
> plugins collection: More and more plugins are going into some kind of an
> orphaned state. There is some maintainer available but not really
> responsive e.g. due to workload at reallife etc. However, at the end
> some of the plugins are still compiling but not effectively working any
> more with recent Geany version or its documentation is really outdated
> -- when I was preparing the commits for waf removing I have seen plugins
> still depending on Geany 0.16 ... I'm pretty sure, if they would, they
> would compile any more ;)
>
> Also the documentation of each plugin are differing in style, size and
> quality much. (and I have to include the plugins I'm maintaining here
> 100% too). At github we already got a bunch of bug reports and pull
> requests for plugins waiting for any response. Also there is a long
> backlog at sf I've been told.
>
> This is what I was thinking of to improve the situation (the overall
> experience for our users)
>
> 1) Deactivating all plugins / out comment all plugins from MAINTAINERS
> 2) Cleaning off NEWS, Changelog etc. from individual plugin folders
> 3) Moving documentation of all plugins into a structure like
>     doc/<pluginname> to get a real fitting (online) manual. At this
>     point update documentation and bring them to some markup stil (Rest?
>     md? Docbook? I don't care at this point)
> 4) Moving all plugins into a subfolder like plugins/<pluginname> to
>     clean up / of g-p a little
> 5) Reactivating plugins by a pull request of the actual (old|new)
>     maintainer maybe doing steps 2-4 and comment back in the plugin in
>     MAINTAINERS. Also I would be happy if at this point po/POTFILES.in
>     is reviewed etc.
> 6) Release a cleaned up g-p
> 7) Post 1.27 puring not update plugins from src tree
>
> What do you think about this idea? I would combine this with some
> release goals like complete support of Geany Gtk3 stack (if applicable).
>
> Timeschedule: 1-4 until Xmas 2015, 5-6 until March.
>


Perhaps we should rethink what g-p is, or what we want it to be.

IIRC it was born simply as a collection of random plugins with two major 
purposes/requirements:
- unified build system including shared translation(s)
- combined release, thus shared release cycle

And nothing more than that. I don't think it was ever planed to 
establish some kind of minimum code quality or frequent maintainer 
actions. It was simply meant to provide a convinient service to plugin 
authors.

In the light of the above, I do think that current g-p is doing well and 
doesn't need to change (perhaps apart from cleaning multiple plugins 
doing the same thing). Plugins shouldn't be removed without good reason 
(i.e. if they're broken).

However, if we now start to add requirements to the above, then yeah, 
some actions like the ones Frank mention should be taken (perhaps 
removing dormant plugins). Keep in mind though, that that may mean 
*additional* burdens for maintainers, now and potential future ones, 
which I think is against the initial purpose of g-p.

Best regards.