Alex headshot

AlBlue’s Blog

Macs, Modularity and More

Gerrit at Eclipse

2012, eclipse, gerrit, git

I wrote yesterday about the use of Gerrit going live at the Eclipse Foundation. Changes may now be submitted and reviewed at https://git.eclipse.org/r/.

The EGit and JGit teams heavily use Gerrit for their reviews (and have done long before this was an officially provided service) but the momentum will be gathering shortly with other projects. Some are debating whether to use Gerrit for all changes, or just for external contributions; the advantage of all changes is that it opens the review process up to everyone and is easier to involve changes from outside contributors than if there’s two paths to the repository.

However, the Git Contributions document is a little outdated, and requires the user to assert that:

Contributor asserts on the corresponding bug or in a comment on the Gerrit push record that they:

  • authored 100% the content they are contributing
  • have the rights to donate the content to EPL
  • contribute the content under the EPL

…at this point in time, we require that the contributor explicitly consent to the Terms of Use when an account is created; we further require that the contributor assert the three questions with each contribution. Consent can be given either on the Bugzilla record (if one exists), or on a comment connected to the Gerrit push.

Quite apart from missing the point about a Gerrit push (it’s not a push, it’s a commit) this also misses one of the most valuable parts of the Gerrit process, which is to allow a user agreement to define what the terms of contribution are. Gerrit supports the possibility of having these questions, answered at user creation time, for all subsequent pushes.

As with changing any legal agreement, however, the legal team have to be involved and changing this may take time. There is a strong desire to make this better (and to avoid the fact that it’s fairly widely ignored at the current time, since contribtions are often taken under the ‘Eclipse Website Terms of Use’ which already covers such code grants (collectively “Material”).

In any case, in the meantime, you can configure Git to automatically add the random IP cruft when you commit the code from the command line. (EGit 1.2 does not appear to observe the commit.template however.)

Adding a Random Eclipse Template to your commit messages
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
cat > ~/.eclipse_template <<EOF
# First line describes the intent of the change

# The first line should be less than 50 chars and explain the intent
# There should then be a blank line and a more descriptive explaination
# of the fix. The commit message should not just be a link to a bug
# in a remote tracking system, as that loses context when traversing
# the log.

# Mutliple paragraphs can be used to add more information where 
# necessary ensuring that paragraphs are split around line 72. This 
# assists printing the message in the log and other locations.

# This is required by the current process, documented at:
# http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions#Gerrit
# BEGIN RANDOM ECLIPSE IP PROCESS CRUFT
I hereby assert that I authored 100% the content that I am contributing
I hereby assert that I have the rights to donate the content to EPL
I hereby assert that I contribute the content under the EPL
# END RANDOM ECLIPSE IP PROCESS CRUFT
# See http://bugs.eclipse.org/371412 for more details

# Add bug number if applicable; remove if not applicable
Bug: 
EOF
$ git config commit.template ~/.eclipse_template

Using this template will permit code commits to pass the draconian processes until such time as the issue is swept away with the Gerrit contributor agreement and the Eclipse Website Terms of Use.

For those who are new to Gerrit, you might want to have a look at some of the demos that I have recored and posts that I have written on Gerrit before.