[Geany-devel] Some sort of thoughts about geany-plugins-devel-git-repo
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
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.
> 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.
More information about the Devel