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

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|,,%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)). A correctly enabled account should see lots of activity.
* Go to the [gerrit 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 ([,ssh-keys|,ssh-keys]) is important. Folks have been bitten for not doing the username setup while setting up SSH keys.

** Add an entry for to your .ssh/config file: {code}
Port 29418
User <Your gerrit Username>
{code} This will enable anonymous ssh to gerrit (ssh -p 29418
* 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|]{note} 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|]!
* Read [this blog post about good commit messages|]!
* 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|] 652|]
** [Change 963|] 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.