We love contributions
Do you have any particular contribution in mind?
Gerrit for code reviews. The process is a little bit different from Github’s pull-requests so it’s a little bit more involved, but know that there are improvements on the way (like a bot that attempts to port PRs into Gerrit, or the possibility to login with Github accounts).
Basically, right now you need to:
- have an OpenID account somewhere (I use Ubuntu LaunchPad)
- sign in to review.couchbase.org using said OpenID (for launchpad the login is in the form
- go to the agreements setting page and sign the CLA (Contributor Licence Agreement)
- generate (or reuse) a ssh key and import the public key into Gerrit
After that, you’ll be meeting the prerequisites to contribute.
Getting Ready to Contribute Code
The wiki page on contributing contains more detailed steps, especially on how to correctly clone and set up a project, so I encourage you to look through it after reading this message.
Michael Nitschinger and I (Simon Baslé) are the reviewers for both
The commit messages follow this convention (see history on Github for examples):
JIRA-ISSUE: Short line of desc (52 chars total)
Paragraph about the motivation behind the change, what was
the problem. Hard line wraps at 70 chars.
Describe what changed. Hard line wraps at 70 chars.
How does it impact the user, do tests pass. Hard line wraps at 70
One thing we’d like to do is tag issues in JIRA that are
ideal-for-contribution, but for now there is none identified as such.
A little crash course on Gerrit’s philosophy:
Gerrit is our canonical repository for changes and each time a
changeset is reviewed, it is picked into the corresponding branch in Github (so Github is the public repository, with a clean history, while Gerrit keeps track of all the intermediate states of a review).
Gerrit works with
changesets, by attributing a
Change-Id to a patch the first time it is committed . But unlike Github’s PRs, you don’t add to your changeset by adding more commits to it. You just
commit --amend (or squash), making sure that the
Change-Id is kept at the end of the commit message, then you push to a special branch .
That way, Gerrit will automatically detect that the commit is another iteration on the same
changeset (called a
patchset). The UI will allow you to review differences between any two patchsets, or the latest+base branch, comment on each patchset, each line of code, etc…
The UI is less sexy than Github’s, but it works and you can enforce good commit history while tracking everything, as well as enforcing submit policies. For instance, we require that a changeset be marked by the author as
Verified +1 to indicate that tests were run and ready to review. Then someone from the project’s team must
Code-Review +2 to indicate the change is ok to merge. Negative score indicate there are still iterations to perform on the change.
 through the use of a Git
refs/for/targetbranchingithub (eg. usually