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

[Matthew Brush]

On 11/15/2011 08:55 AM, 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.
>

The point is closed, see the thread, apologies for not making that clear 
enough. IIUC it's basically just a matter of someone pushing the repo 
unless people have committed to SVN in the meantime I guess it needs to 
be re-processed.  See below for rest of reply.

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

I like this idea, but depending on the criteria, it might become very 
time-consuming (ex. if code reviews were involved for all the changes).

> 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 ;)
>

As I've proposed before, I still think the best option is to use Git 
submodules[1].  IIUC it's basically "the right way" to do what you've 
described above.

Doing it this way, each plugin developer would have their own git 
repository[2] (on github.com or elsewhere), and the "release team" could 
handle the pull/merge requests at critical points.

This has the advantage that each plugin could stand on it's own in 
addition to being part of the "officially sanctioned" geany-plugins 
project. IIUC people could choose to just checkout the one plugin or the 
whole lot of them, or even just clone the plugin's main repository.

With some changes to the build system(s) it should be possible to make 
each plugin buildable on its own or as part of the geany-plugins 
project, as opposed to now, where it's difficult (impossible?) to have 
your plugin build independently of the geany-plugins project and still 
use Autotools (or Waf).

The main advantage though is that it allows this sort of "centralized 
administration" and quality assurance of the main project as you're 
describing, without making it overly complicated, basically just using 
the tools we already have available.

I could probably fill another email or two with other advantages of 
doing it this way, but I'm trying not to be so verbose :)

Cheers,
Matthew Brush

[1] http://help.github.com/submodules/
[2] or have a repository for each plugin under the geany organization, 
with the appropriate permissions, which IIUC is what XFCE and GNOME do, 
for example.