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)
- Deactivating all plugins / out comment all plugins from MAINTAINERS
- 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.
- 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?
- 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.
- 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.
- Release a cleaned up g-p
- 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.
Cheers, Matthew Brush