I'm currently doing some university lab which involves contributions to the
ZooKeeper project. For my report I summarized the process of getting a
into an ASF project. You can skip the description and jump to my offer for
help to make GIT available for the ASF.
The work flow to make changes in the ZooKeeper project is very
First a patch file needs to be created. This patch then has to be uploaded
the issue tracker as well as to the review system. However one usually
to upload the patch to the review system only after the continuous
system did successfully test it. Such a test run is triggered by a cron job
that scans the issue tracker every 5 minutes for new patches. The test run
itself takes about 20 minutes.
Uploading the patch to the review system is again a multi step process:
the web interface, select the project, select the patch file in the browser
file dialog, select the reviewers group, select the corresponding issue,
These steps of course need to be repeated if the reviewer demands changes.
Care must be taken to keep the patch files on the issue tracker and in the
review system in sync to avoid confusion.
But even if no updates to the patch are demanded, it may be necessary to
update the patch because changes have been made to the project's trunk in
meanwhile and the current patch can not be applied anymore.
If that wouldn't be complicate enough, the process does not work for binary
files, since the patch files can not express them and is brittle in
It seems for example that the continuous integration system may not always
to apply the patches on a clean checkout of the trunk but on some dirty
To solve the headaches described above, I propose the introduction of the
review system Gerrit together with GIT. Then the patch process for the
committer would be reduced to a simple invocation of "git push gerrit".
In the background the following things happen:
* Gerrit either creates a new change to be reviewed or detects an update
an existing review
* The change description is taken from the commit message
* Gerrit scans the commit message for an issue number and can post a
to the issue tracker
* The jenkins-gerrit-plugin _immediately_ starts to test the change and
its result as a comment to Gerrit
* After a successful review Gerrit automatically merges the change in the
trunk, using the merge capabilities of GIT. Only in rare cases would it be
necessary to update patches because the same file has changed in trunk.
* Problems with dirty checkouts in Jenkins or binary files don't exist
Jenkins uses GIT instead of handling patch files. Issue tracker and review
system syncing is not a problem because patches are only in the review
Votes are recorded in Gerrit.
I've set up a Gerrit-Jenkins combo on my own server for my work on
How can I help? I'm living in Switzerland. I'm not an Apache committer.
Thomas Koch, http://www.koch.ro