compared with
Current by Colm Mchugh
on Oct 13, 2014 06:15.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (13)

View Page History
* Login using your favorite OpenID provider.

* Send [me|mailto:dustin@couchbase.com,matt@couchbase.com?subject=Hey,%20I'm%20a%20gerrit%20user] 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)). Make sure you get into the Northscale group for gerrit to work correctly. A correctly enabled account should see lots of activity.
* Go to the [gerrit settings|http://review.couchbase.org/#/settings/] and click on "Agreements" on the left hand side. Contributor agreements are needed for all projects except spymemcached. _Note to *new Couchbase employees*_: you should contact the helpdesk as your process is slightly different.

* While you wait for approval...
* To complete the setup...
** Go through gerrit's Settings screen and set up your SSH keys. _IMPORTANT_: - do not forget to setup your username on the Settings screen.
** Again, the username setup in gerrit \-> Settings \-> SSH Keys ([http://review.couchbase.org/#settings,ssh-keys|http://review.couchbase.org/#settings,ssh-keys]) is important. Folks have been bitten for not doing the username setup while setting up SSH keys.

** Add an entry for review.couchbase.org to your .ssh/config file: {code}
Host review.couchbase.org
HostName review.couchbase.org
Port 29418
User <Your gerrit Username>
{code} This will enable anonymous ssh to gerrit (ssh -p 29418 review.couchbase.org)
* And setup your contact information if you'd rather use a different Email address.

h1. Initial Project Setup (for each project)

{note}This is not necessary if you intend to use repo. For a repo with membase quick start, please see the README in our [repo manifest|https://github.com/membase/manifest]{note} manifest|https://github.com/couchbase/manifest]{note}

Next, you'll need Change-Id's in all of your commit messages.
h2. 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). By the way, don't see a reject as a bad thing. More eyes on a change will usually give it higher quality. It's less effort to fix things before they go in than after they're in a release.

* {{git checkout my-rejected-topic-branch}}
h2. Phase 3: Submit

Once the change is all verified, we can submit. We generally 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.

* Read [this information about good commit messages|http://en.wikibooks.org/wiki/Git/Introduction#Good_commit_messages]!
* Read [this blog post about good commit messages|http://chris.beams.io/posts/git-commit/]!
* The best commit messages are like little blog posts.
** These can help to "sell" your commit to the community.
* Here's examples where the commit message was much longer than the actual fix, but provided useful context as those one-liner fixes can sometimes be very intricate...
** [Change 652|http://review.membase.org/652] 652|http://review.couchbase.org/652]
** [Change 963|http://review.membase.org/963] 963|http://review.couchbase.org/963]
* On style, don't have giant long lines, especially on your first summary line. More detailed information can be found
* The best commits, too, are just like UNIX Philosophy.