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)
- Deactivating all plugins / out comment all plugins from MAINTAINERS
- Cleaning off NEWS, Changelog etc. from individual plugin folders
- 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)
- Moving all plugins into a subfolder like plugins/<pluginname> to clean up / of g-p a little
- 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).
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.