[Geany-devel] Some sort of thoughts about geany-plugins-devel-git-repo

[Frank Lanitz]

Am 16.11.2011 07:12, schrieb Lex Trotman:
> 1. Individual plugin maintainers shouldn't care about all the other
> plugins in the combined release

Not a written, but existing rule.

> 2. Users getting the combined release to build should get everything
> in one command

ACK.

> 3. The combined release maintainers still need to be able to make
> changes to each plugin in case of urgent bugfix and temporarily or
> permanently missing individual plugin maintainer.

ACK.

> 4. Not all plugins are in the combined release, due to quality,
> timing, or maintainer availability issues.  But users rely on plugins
> so it is bad to remove their availability.

ACK

> Having a single repository with branches fails item 1. since Git can't
> do partial checkouts/clones so all maintainers have all plugins and
> have to see all changes, a lot of noise.  And accidental changes to
> parts of the tree outside the users plugin can be committed and
> pushed.

I disagree a bit here.
The goal is to have your own branch and work on your own branch for your
plugin. Ones this is done you are sending a merge request to
$release_team. You will not see whole noise - only if you do a git merge
or rebase against master.
Of course the commit and push is possible. But release team is asked to
block such requests.

> So I suggest that each plugin needs to have a separate repository
> under the Geany organisation.  The plugin maintainer can fork these
> for development of their individual plugin in complete freedom and
> push to the repository when the plugin is ready providing item 1.
> These repositories also ensure Geany has a copy of the plugin under
> project control to prevent them disappearing or changing unexpectedly
> and to allow local bugfixes and quality checks to be made, providing
> item 3.  I understand that access can be limited to specific repos so
> maintainers can't accidently change another plugin.

I did this with GeanyLaTeX, GeanySendMail and some of the others for a
while and it wasn't worth as it was twice effort. It will not work out
as most of the maintainer currently aren't able to do basic maintenance
in time, they will not be able to do extra efforts e.g. for having a
local build system which you will need.

> The combined release has its own repository that refers to the
> individual plugins ones.  Git submodules allow the combined repository
> to point to specific versions of the individual plugin repositories,
> perfect for release functionality.  Pushes from maintainers are not
> automatically included in the combined release until they have been
> quality checked.

In general its a good idea, but for geany-plugin's purpose I'm not with
you.

> Unfortunately this violates item 2 since users checking out the
> combined release need to know to pull the subprojects, a somewhat more
> esoteric thing than "git clone
> git://github.com/geany-plugins/geany-plugins.git" but we can put the
> necessary command in readme and other places.  Other than that only
> the combined plugin maintainers need to know about the subproject
> technology, not individual plugin maintainers.  This keeps the entry
> cost low for plugin maintainers.

Hmmm.... No. Do users remember that the have to do regularly git
submodules update?

> Note that a plugin that fails to meet quality requirements, or some
> other criteria for inclusion in the combined release, still has its
> own repository available to users.  So plugins can be added or dropped
> from the combined release whilst still being available to users from
> their individual repository, providing item 4.

This can be solved by deactivating the plugin in general build flavor by
setting the autotools and waf parameters to Don't build. If user want to
have, they could use --enable

Cheers,
Frank

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