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

[Frank Lanitz]

On 22.11.2015 12:48, Thomas Martitz wrote:
> 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)
>>
>> 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)
>> 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).
>>
>> 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.

Indeed that's a good question. IMHO g-p should be something for users.
Therefore everything we do should fit with what a user would expect. I
don't think about everything working out of the box with one click, but
thinking about an user downlaoding an extension pack and wanting it to
install and use with without collecting 200 different libraries and
checking for documentation in 20 places. So there needs to be a single
point to step in like an README and a single point or at least a
reasonable place for documentation on how plugins work. Also I don't
want to have a user having git, hg, bzr (read: many addition tools and
steps to start finally compiling plugins) installed to just get the
sources to make latest release-tarball running.
Of course, I hope all plugin maintainers and contributors are users too
so it should fit their developing process ;)

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

No. It was also meant to be a single point of contact for users. But we
established it >7 years ago so I might remembering wrong -- and I don't
want to grab archives as at least I didn't expect at this point Geany
will become every this popular and we will have more than maybe 20
plugins at all.

The more important question for me is what will it be in future?

Cheers,
Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.geany.org/pipermail/devel/attachments/20151122/d4e3799d/attachment.sig>