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

[Alexander Petukhov]

On 11/15/11 8:55 PM, Frank Lanitz wrote:
> 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
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi there,

I also vote for increasing plugins quality, but as for me Franks ideas 
about different branches seem a bit overcomplicated.

Maybe we can use git pre-commit hook to prevent commits that breaks some 
quality criteria?
http://book.git-scm.com/5_git_hooks.html
To be honest I didn't get much into details but it seemed to me that it 
can handle quality check tasks.

So my suggestion is still to use a single common repo for all plugins 
and use commit hooks to prevent unqualified code.

This requires that at some point all plugins in this repo pass this 
quality check, and here is what I suggest - move plugins from svn one by 
one,
checking code for quality.

For those that didn't pass we can create a distinct repo under geany 
organization. Once a maintainer or a volunteer refine a code to fit the 
requirements it can be
moved to a main repo. Until then it can be still available but won't be 
included in g-p release (maybe we can create distinct release 
geany-plugins-unsupported, as IIUC I already suggested once).

To easily move plugins between probably it's a good idea to use 
submodules, IIUC this is svn "externals" analogue.

To make every plugin compile and build independently I vote for 
eliminating common "po" catalog, that I also suggested recently,
this will also help to avoid translations intersection between different 
plugins.

Renaming plugins in sense of removing "geany" prefix also can be done 
while moving.


So, here are the steps:

1. create distinct "po" catalog for every plugin, update build systems 
to allow building plugins individually
2. create code quality tests that can be used in git pre-commit hook
3. move plugins that pass a test to a "geany-plugins" GitHub repo 
(renaming if needed)
4. move the rest of plugins to a "geany-plugins-unsupported" GitHub repo 
(renaming if needed)

What do you think guys?

Regards,
Alexander