Jump to: navigation, search

Zaqar/Your first patch

< Zaqar(Redirected from Your first patch (Zaqar))

Learn how we work

Set up your contributor account

Set your local repository

Clone Zaqar's code

git clone git://git.openstack.org/openstack/zaqar.git

To set Zaqar up you will need to install some dependencies and do some basic configurations. Check out how to set up a Zaqar's basic deployment in Zaqar's repository in Github.

Testing the features is always a great way to break the ice with the project and it helps to understand the code better.

Before starting to code, you will have to do some configs to connect your local repository with Gerrit (you have to do these the first time only!).

You may want to ask Git-review to configure your project to know about Gerrit so the Gerrit Change-Id Commit hook gets installed. To do so:

cd zaqar
git review -s

Git-review checks that you can log in to Gerrit with your SSH key. It assumes that your Gerrit/Launchpad user name is the same as the current running user. If that doesn't work, it asks for your Gerrit/Launchpad user name. You can avoid that question by configuring your Gerrit username, as follows:

git config --global gitreview.username yourgerritusername

If you don't remember your Gerrit user name go to the settings page on Gerrit to check it out (it's not your email address).

Note that you can verify the SSH host keys for review.openstack.org here: https://review.openstack.org/#/settings/ssh-keys

If you get the error "We don't know where your Gerrit is", you will need to add a new git remote. The URL should be in the error message. Copy that and create the new remote.

git remote add gerrit ssh://<username>@review.openstack.org:29418/openstack/zaqar.git

In the project directory, you have a `.git` hidden directory and a `.gitreview` hidden file. You can see them with:

ls -la

Once you have this done, you can start working on your patch!

Hack, hack, hack!

Pick a bug

You can start tacking some bugs from the bugs list in Launchpad. When you find a bug you want to work on, just assign yourself. Make sure to read the bug report and, if you need more information, ask the reporter to provide more details.

If you find a bug that it's not in the bugs list in Launchpad (props for that!), just report it and wait for another developer to confirm it. When it's confirmed, you can start working on it.

To start working on your bug, make sure to follow the development workflow.

Design principles

Zaqar lives by the following design principles:

  1. DRY
  2. YAGNI
  3. KISS

Try to stick to them when working on your patch, the reviewers will appreciate that!

Submit your patch

Once you finished coding your fix, go ahead and submit it for review]. Be sure to format your commit message appropriately. The first thing to watch for is a +1 in the "V" column next to your patch in the server and/or client list of pending patches:

If the "Jenkins" user gives you a -1, you'll need to check the log it posts to find out what gate test failed, update your patch, and resubmit.

Once the gate has verified your patch, other Zaqar devs will take a look and submit their comments. When you get two or more +2's from core reviewers, the patch will be approved and merged; well done!

Note: If a reviewer submits their comments with a "-1", don't be discouraged; he or she just wants to make sure you and other reviewers notice the submitted question or suggestion. When replying to feedback, you as the patch author will typically just use the score of "0". The only exception is when you discover a blocking issue and you don't want your patch to accidentally get merged while you are discussing the patch with the team; in that case, you can vote on your own patch with a "-2", while you decide whether to keep, refactor, or withdraw the patch.

Professional conduct

The Zaqar team holds reviewers accountable for promoting a positive, constructive culture within our program; if you ever feel that a reviewer is not acting professionally or is violating the OpenStack community code of conduct, please let the PTL know immediately so that he or she can help resolve the issue.

Common Problems

1. You realized that you were working in master and you HAVEN'T made any commits.


git checkout -b newbranch     #if you already created the branch, omit the -b
git commit -a -m "Edited"

Now all your changes are in newbranch. Problem solved!

2. You realized that you were working in master and you HAVE made commits to master


git branch newbranch
git reset --hard HEAD~x    #x is the number of commits you have made to master. YOU WILL LOSE ANY UNCOMMITTED WORK
git checkout newbranch

Your commits are now in newbranch. Problem solved!

3. You made multiple commits and realized that Gerrit needs one commit per patch You need to squash your previous commits. Make sure you are in your branch and follow this guide. Fill in the commit message as specified on the Developers' Guide page