Heat Development Process Guide

This is a guide to the development process for contributors to heat

Prerequisites

All contributors to heat must sign the openstack contributor agreement:

http://wiki.openstack.org/HowToContribute

http://wiki.openstack.org/CLA

You must have a [launchpad](https://launchpad.net/) account, with your SSH key registered.

Issue/Bug Tracking

All issues (bug fixes and enhancements) are currently tracked through https://bugs.launchpad.net/heat.

If you want to work on a fix or new feature please raise a new issue for it (unless one already exists) and assign it to yourself, so other developers know you are working on it.

Coding Style/Standards

Wherever possible heat aligns with existing openstack code structure and conventions, and in addition all code must pass pep8 style rules before it can be merged.

When starting work on new features it is recommended to look at existing openstack code where appropriate to see if there is common code which can be reused, or stylistic or logical patterns which can be copied.

Git usage/tips

When using git commit, use the "-s" option to sign the commit

git commit -s <some file(s)>

This will place a "Signed-off-by: Your Name <youremail> at the end of the commit message

If the signoff gives something unrelated to your login or email, you can configure git permanently with:

$ git config --global user.name "Firstname Lastname"
$ git config --global user.email "your_email"

When preparing a commit, rebase your commit on top of latest master prior to submission for review, and optionally use interactive rebase to combine local "interim" checkins to logically related changes.

Do not combine logically unrelated changes in the same commit.
Do not combine bugfixes and enhancements in the same commit.

git commit -s <some file>
git pull --rebase
git rebase -i origin

Submitting Patches for Review

Heat uses the openstack gerrit/jenkins workflow to manage merging patches into git master - no pushes direct to the repository are allowed.

Workflow is to run "git review" when you are ready to submit changes from your local tree for review.

Note the following:

If you have several commits locally, each commit will be submitted as a separate review, with each depending on the previous commit.
Patches are gated on all unit-tests and pep-compliance tests passing - run run_tests.sh before submitting!

Install git review if not already on your system:

sudo yum install git-review

When your ready to commit a patch, commit/sign as normal:

git commit -a -s
One line description of change < 50 characters

longer description of change, may be multiple lines

Send the patch to gerrit:

git review

After submission, git review will print a URL on https://review.openstack.org - it's a good idea to paste this into your IRC client on #heat on freenode, so other developers are more quickly aware there is a pending review.

Stackforge infrastructure will do the following:

run the unit tests on python2.6
run the unit tests on python2.7
run pep8

If the tests/pep8 succeed, the patch needs to be manually reviewed. Once reviewed it will be automatically committed/merged by jenkins.

If there are code review comments requiring rework and resubmission you can do the following:

<Make code changes>
git commit --amend
git review

This uploads a new patchset at the same URL to review.

Heat/DevelopmentProcess