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

[Frank Lanitz]

Hi,

On 21.11.2015 22:34, Matthew Brush wrote:

>> 1) Deactivating all plugins / out comment all plugins from MAINTAINERS
>> 2) 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.

Yes. And this is the reason why I'd like to purge them. The reason why
they are there is IIRC an ancient need on something at autotools.
Currently beside of Scope it's just adding noise to the repo and mostly
outdated files.

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

This is the exact point I want to get rid of. IMHO geany-plugins is one
package and should behave like on package to the enduser when
downloading the geany-plugins-release tarball.

In past having a project here and a copy there confused users a lot and
it's adding overhead to plugins maintainer IMHO. Also having
documentation here and there ended up in the mass of documentation we
currently have. Current feature of plugins.geany.org is a good
workaround but in time not the solution.

There might needs another solution for having g-p plugins and more
plugins. Of course if we can integrate them into g-p it would be a
benifit. I see adding e.g. geanypy just as distribution of geanypy for
convenience not as main feature. (not saying anything the plugin itself)

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

Good ;)

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

Good point. Even when distributing with g-p there is really no need. As
I'm having a bunch of geany*-plugins maintained the main reason was they
started as project outside of g-p.

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

Which ones do you think of? I would say scope and debugger could be one
pair of it. What else? And how to solve it as they do differ in target
group and usecases I guess.

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

No, well, yes ... hmmm. I was thinking about that point and got to the
idea, that I'd prefer a maybe smaller g-p with near cycle to geany-core
as e.g. pidgin is doing it with some of the plugins. However, it could
be possible.
My main goal is having a src tarball at the end, which includes
- Global, minimal README
- Global NEWS, Changelog
- plugins/-folder including all plugins code
- doc/-folder including all plugins documentation

This could be also done during e.g. make dist. So a make dist could do a
git submoule update etc. So pretty much I'm ok having a special rule for
external plugins on git, but when packaging is ready it all should be
all of a piece IMHO. How can we ensure the documentation fits together?
What to do with translations? Please convince me ;)

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/67274624/attachment.sig>