Am 16.11.2011 07:12, schrieb Lex Trotman:
- Individual plugin maintainers shouldn't care about all the other
plugins in the combined release
Not a written, but existing rule.
- Users getting the combined release to build should get everything
in one command
ACK.
- 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.
- 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