[Geany-Devel] Geany-Plugins rework -- RFC
mbrush at xxxxx
Sat Nov 21 21:34:55 UTC 2015
On 2015-11-21 5:42 AM, Frank Lanitz wrote:
> 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
I don't think I ever edited these files for my plugins, at least not
after adding the plugin initially. All changes are in the Git log.
> 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)
I don't like that all plugin files aren't self-contained inside own
plugin dir. The "build" directory is already like this, plugins have to
put M4 files separately into that dir. Maybe we could have a script
that, when generating the manual, can just automatically combine all the
markup files from each plugin dir?
> 4) Moving all plugins into a subfolder like plugins/<pluginname> to
> clean up / of g-p a little
This sounds OK, clean up the root dir a bit.
> 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).
I would add;
8) Rename all plugins that start with "Geany" to remove the "Geany"
prefix. It's annoying in the plugin manager and in the source tree
having all kinds of plugins clustered at the letter G, and obviously the
plugins are for Geany.
9) Remove redundant plugins. Have a rule that only one plugin to do one
thing is allowed and if someone wants to work on a plugin, they should
either work on the existing plugin, or else give reasoning why a new
plugin should replace the existing one. It's too confusing for users,
and they end up using the wrong (old unmaintained) plugins.
10) Support for Git submodules so plugins don't have to be forked to be
included in Geany-Plugins collection, they just need to use Autotools as
their build system. This would also require making the build system to
support building the plugins using (parts of) their build system.
More information about the Devel