Initial Account Setup

Send me the email address you came in with so he can add you to the right gerrit group (otherwise you'll see only a couple or fewer fixes for review (these are likely open-source fixes)). A correctly enabled account should see lots of activity.

While you wait for approval...

Go through gerrit's Settings screen and set up your SSH keys. IMPORTANT: - do not forget to setup your username on the Settings screen.

You should next go into the gerrit's web page for the change's and add reviewers. Otherwise, it's unlikely anyone will review your code. Adding a reviewer causes the change to show up in the reviewer's "Reviewable by me" list, and they also get an email.

Others will go and review your code (you can also request reviews specifically in the admin UI).

Review Workflow

It's good to learn the key combinations (hit ? anywhere), but in general, you can see all of the open changes by going to All -> Open and digging through them.

Phase 1: Reviewable

Dig around, look at things to review, and throw in your comments. You can comment on individual code lines.

Also, with regards to dependencies, if the fix you're reviewing depends on another fix, review the dependency first. That is, follow the dependency link trail until you hit a fix that has no dependencies. This helps ensure the right cherry-pick sequencing (gerrit does cherry-picking automatically for us if we do it right).

It takes two points for code to be acceptable. Everyone has two points to spend on a given change. Use them wisely.

Phase 2: Needs verification

You can do this at the same time as the review, but you have the ability to pull down the changes to test locally.

Phase 2.5: Rejected!

If your code was rejected, it's time for a fix and retry: Fix, rebase, repeat (the Change-Id will keep old comments in sync).

git checkout my-rejected-topic-branch

$EDITOR broken-file.erl

# Rebase against the current upstream, fixup changes while maintaining Change-Id

git rebase -i gerrit/[BRANCH_NAME]

For example: git rebase -i gerrit/master

git push gerrit HEAD:refs/for/[BRANCH_NAME]

For example: git push gerrit HEAD:refs/for/master

The rebase session will begin with you in an editor that looks something like the one to the right:

At this point, your current patch should be replaced with the new, fixed up version.

Phase 3: Submit

Once the change is all verified, we can submit. We use cherry-pick, which means we need to be a bit careful to do this in order.

Once the submit is complete, the change will automatically show up on github, as we publish changes there too.