Actions

Working with Gerrit as a Reviewer

Reviewing changes

All code review happens via the http://review.typo3.org interface. You should log in there using your typo3.org user credentials, and make sure that the email address points to somewhere you'll read regularly.

You'll be presented with a list of patches requiring review or, if someone has asked, patches you've been explicitly requested to review. There are two types of review - Code Review and Verification. Code Review means that you have read through the code, and are satisified that it works properly, follows the tree's style, and generally doesn't suck. Verification means that you have taken a copy of the patch and tested it. We will automate the verification step through our CI server Hudson, but generally both should be perfomed (also) manually.

Code Review

To perform a code review, go through each of the diffs in the current changeset for the code you have decided to review. You can double click on a line to leave a comment. Once you have completed commenting, click on the 'Review' button that's about 3/4 of the way down the page containing the list of patch sets. You will then be asked to score the patch, with a range from -1 to +1. -1 means that you don't think the code should be applied, +1 means that it is good to apply. You can also leave further, general, comments for the patch submitter.

Note that no matter how many +1 or -1 comments a patch receives, the team members can override these to either permit or forbid submission by giving -2 or +2 on a patch ("gatekeeper" permissions). Also, at least one team member must approve a patch in this way before it can be submitted to the tree.

A +2 means that the patch can be submitted. A -2 means that the patch is rejected. Note that these scores are not additive (2 +1s do not make a +2, 4 +1s don't cancel out a -2). This means that gatekeeper's scores are definitive - it doesn't matter what others may score, although that should probably be used as a guide.

In a specific project certain additional rules may applay as to who is allowed to give final acknowlegdement, so make sure to know what you are doing.

Verification

To verify the code, pull the git copy into your local tree, using the git command listed as part of the patch details. For sanity's sake, we'd strongly recommend you do this pull into a topic branch you've created for the purpose. Build it, test it, and report your results. Note that a single -1 to verification can block patch submission, so please use these options wisely. If in doubt, score 0 and leave your comments. Please indicate which platforms you have tested on, and what testing you performed when verifying.

Gatekeeper tasks

When a patch is reviewed and verified a few tasks are still open.

Submitting the patch

Once a patch has both a +2 code review, and has verified OK, it may be submitted. A Submit button will appear on the patch's gerrit page - when clicked, the patch will be pushed into the git tree.

Dealing with conflicts

You may find that attempting to cherry-pick a patch via gerrit results in a conflict. One way to address this is to modify the commit. Start with a current repository, cherry-pick the commit, fix it, and push back to gerrit.

git fetch
git checkout -b <new-topic-branch>
git cherry-pick <sha1 of contribution>

The cherry-pick will give you a warning like
Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
When commiting, use the option '-c 822e735' to retain authorship and message.

if it fails. At this point, resolve the conflict. You can use git diff to determine what it is. Then, continue:
git add <file with resolved conflict> [<next file with resolved conflict>]
git commit -c <commit hash from cherry pick>

Confirm you will push the right thing:
git log -p origin/master..HEAD

Then, push the change back to the open issue in gerrit.
git push ssh://review.typo3.org/<projectname> HEAD:refs/for/<branch>

Modifying a change in gerrit

The typical gerrit workflow expects that instead of gatekeepers modifying changes in gerrit, they will simply leave review comments and expect the committer to fix their patch to address those comments themselves (the theory being that this educates the committers, and thus reduces the load on the gatekeepers in the long term). However, if you want to modify someone's change, you can do so.
Simply fetch the change from gerrit as if you were going to verify it, making sure that you do that fetch into a topic branch. Then, make your modifications and run

git commit --amend --author "A.N. Author <a.n.author@example.org>"

Then push this commit into gerrit as a replacement from the original change (see above for details of exactly how to do this)

Special tasks

Tagging releases

When tagging only annotated or signed tags will be accepted (lighweight tags can be used locally, of course). To be able to push a tag to gerrit you need to be in the "Taggers" group.

git tag -a <tag>
git push ssh://review.typo3.org/<projectname> <tag>

Updated by Peter Niederlag over 10 years ago ยท 5 revisions