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

Thomas Martitz thomas.martitz at xxxxx
Wed Nov 16 12:06:09 UTC 2011


Am 15.11.2011 17:55, schrieb Frank Lanitz:
> We will have one master branch where all changes intended for releasing
> are going in. Features and new plugins are going to be developed inside
> branches (more late onto this topic) and once they are in a suitable
> status, they are getting merged into master branch.
> Release are generated from master branch and are getting marked with a
> tag. If there is any need for some minor release as we had e.g. with
> 0.21.1 there will be a release branch that will include all patches
> going in. If they are also needed to get applied on master, we can
> cherry-pick them or find some other way of merging them back.
>

I like this proposal. Requiring pull requests will also formally mean 
"get your plugin in shape" before release. I'd like to extend this to 
the point that if a plugin is not ready (due to bad code, inactive 
maintainer, or otherwise) the snapshot from the previous release will be 
taken as to not lose functionality (this is in most cases automatic, 
since the merge didn't happen). I strongly advice against delaying 
releases for individual plugins.

However, there's one problem that isn't addressed, and I'm not sure it 
can be technically since it's more a cultural problem: There's IMO too 
little collaboration on plugins. It's kind of "each plugin to its 
maintainer", with little to no collaborative effort to form the best and 
greatest plugins. It feels like the source is available but not really 
open. OTOH perhaps my perception is just wrong, and this cannot be fixed 
by technical measures anyway.


Regarding the ideas with separate repos/submodules: This basically 
breaks what the initial idea of geany-plugins was. To share 
infrastructure, build system and translations. The "combined release" 
idea came actually some time after that.

If the repos are separate and only merged for release, then they can 
just as well be separate entirely. So I disagree with that.They should 
be one repo, since they share a common code base via the translation and 
infrastructure.

Am 16.11.2011 07:12, schrieb Lex Trotman:
> Although I am not a plugin developer I have a couple of suggestions
> based on the following needs:
>
> 1. Individual plugin maintainers shouldn't care about all the other
> plugins in the combined release

Not caring about other plugins is ok, but that doesn't mean his 
clone/checkout must not have other plugins.

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

This is status quo, and should be kept, yes.

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

I agree.

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

Covered by my suggestion to simply re-use the previous release.

Best regards.



More information about the Devel mailing list