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

[Frank Lanitz]

Hi developers,

It has been a while when I first announced a mail about my idea of
process after transition of geany-plugins repository. As from my
understand the only open point is to have clarified the
svn-url-reference question its a good point to tell you what I'm
thinking of.

Currently we do have about 25 people which are allowed to commit to
geany-plugins svn. Not all of them are active at the moment (and might
won't get active again sometime in future), some of them are low in time
or no responsive at the moment.

On the other hand we do have about 30 plugins, which are mostly
maintained. As you know from discussion about e.g. geanydbg/debugger and
the project plugins, some of them are currently not maintained very
actively and are getting obsolete.

Given the changes for Python plugin support in pipeline of Geany I'm in
a good mood that we will have a increasing number of contributors and
plugins available for Geany. Some of the new plugins will be distributed
via the geany-plugins-project for sure as well as contributors like to
add maybe features, bugfixes etc. to existing code basis.

Unfortunately in past we had not really some kind of a quality assurance
on committing code beside authors and maybe devel users. We introduced
the make check build target a couple of month ago which gave a more
critical view onto code. Based on this a huge number of warnings, memory
leaks and bugs has been able being removed. But still issues are left.

As we will have some kind of a reset with movement to github, its a good
point to rethink about the way, how patches are introduced to
geany-plugins. So this is my idea how to do so:

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.

We can divide contributors for plugins into 2 groups:
1: Contributors to existing plugins or general infrastructure as e.g
waf/autotools
2: Contributors of new plugins
Here we should set up 2 processes:
Contributions of group 1 should clone the repository and sending a pull
request or patch to maintainer of plugins. Once they did this, the
maintainer is reviewing the changes and including them into his branch.
Contributors of new plugins shall send a pull request of full diff to
release team.
And this is another point. I imagine to have a release team which is
taking care of overall quality of geany-plugins. This is including
following: If a plugin maintainer is finishing a change or a review he
is sending a merge request to the release team. After they did a review
based on criteria given e.g. inside HACKING they are merging it into
master branch. If the patch is not hitting a minimum on quality its
getting refused.

Thins to be done in front if you like this change:
- Defining release team
- Reviewing HACKING and defining basic quality criteria
- Pushing all to github ;)

What do you think? Feedback is highly welcome ;)

Cheers,
Frnak