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

Jiří Techet techet at xxxxx
Mon Dec 21 22:51:37 UTC 2015


Hi Frank,

sorry for replying so late. The proposal looks good to me except maybe...

On Sat, Nov 21, 2015 at 2:42 PM, Frank Lanitz <frank at frank.uvena.de> 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
> 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)
>

...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.

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.


> 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).
>

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.

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.

Cheers,

Jiri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20151221/0b4e06a5/attachment.html>


More information about the Devel mailing list