<div dir="ltr">Hi Frank,<div><br></div><div>sorry for replying so late. The proposal looks good to me except maybe...</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 21, 2015 at 2:42 PM, Frank Lanitz <span dir="ltr"><<a href="mailto:frank@frank.uvena.de" target="_blank">frank@frank.uvena.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
<br>
Since a few releases I'm experiencing some not optimal way of<br>
development which is surely caused by the long history we already have<br>
on g-p as well as by the many people around luckily contributing to the<br>
plugins collection: More and more plugins are going into some kind of an<br>
orphaned state. There is some maintainer available but not really<br>
responsive e.g. due to workload at reallife etc. However, at the end<br>
some of the plugins are still compiling but not effectively working any<br>
more with recent Geany version or its documentation is really outdated<br>
-- when I was preparing the commits for waf removing I have seen plugins<br>
still depending on Geany 0.16 ... I'm pretty sure, if they would, they<br>
would compile any more ;)<br>
<br>
Also the documentation of each plugin are differing in style, size and<br>
quality much. (and I have to include the plugins I'm maintaining here<br>
100% too). At github we already got a bunch of bug reports and pull<br>
requests for plugins waiting for any response. Also there is a long<br>
backlog at sf I've been told.<br>
<br>
This is what I was thinking of to improve the situation (the overall<br>
experience for our users)<br>
<br>
1) Deactivating all plugins / out comment all plugins from MAINTAINERS<br>
2) Cleaning off NEWS, Changelog etc. from individual plugin folders<br>
3) Moving documentation of all plugins into a structure like<br>
   doc/<pluginname> to get a real fitting (online) manual. At this<br>
   point update documentation and bring them to some markup stil (Rest?<br>
   md? Docbook? I don't care at this point)<br></blockquote><div><br></div><div>...this one - similarly to Matthew, I would also prefer having all the stuff related to a single plugin in the plugin's directory. What's the problem with the online manual? The build system should know the plugin directories and be able to pick the documentation files from each of them.</div><div><br></div><div>Related to this it would be nice to be able to easily detach a plugin from the geany-plugins repository so it can be e.g. developed separately between releases. But I'm not an autotools expert and don't know whether it's easy/possible to do.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4) Moving all plugins into a subfolder like plugins/<pluginname> to<br>
   clean up / of g-p a little<br>
5) Reactivating plugins by a pull request of the actual (old|new)<br>
   maintainer maybe doing steps 2-4 and comment back in the plugin in<br>
   MAINTAINERS. Also I would be happy if at this point po/POTFILES.in<br>
   is reviewed etc.<br>
6) Release a cleaned up g-p<br>
7) Post 1.27 puring not update plugins from src tree<br>
<br>
What do you think about this idea? I would combine this with some<br>
release goals like complete support of Geany Gtk3 stack (if applicable).<br></blockquote><div><br></div><div>In my opinion things like support for Gtk3 for all plugins are out of the scope of the geany-plugins project as a whole. If the maintainers of the plugins not supporting Gtk3 yet don't have time to add the support and nobody else cares enough to add it then what - remove the plugin because of that even if it works fine with Gtk2? IMO the task of geany-plugins should be to just know which plugins support Gtk3 and build only those which do.</div><div><br></div><div>For me at least geany-plugins is a kind of repository so users can find various plugins easily and at the same time serves geany developers to make changes to all the plugins when e.g. some API call changes. But the individual plugins inside are the responsibility of the individual maintainers. Of course the question is what to do if a plugin gets unmaintained - perhaps the best is to keep it as long as it builds and there aren't any major issues with it.<br></div><div><br></div><div>Cheers,</div><div><br></div><div>Jiri</div></div></div></div>