Difference between revisions of "Heat/DevelopmentProcess"
Line 23: | Line 23: | ||
All issues (bug fixes and enhancements) are currently tracked through https://bugs.launchpad.net/heat. | All issues (bug fixes and enhancements) are currently tracked through https://bugs.launchpad.net/heat. | ||
+ | |||
+ | Bug-fixes and minor enhancements (e.g adding missing functionality to existing resources) adding should be tracked through launchpad bugs, major enhancements and new features should be tracked through launchpad blueprints. | ||
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. | 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. |
Revision as of 15:38, 8 January 2013
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
You must have a [launchpad](https://launchpad.net/) account, with your SSH key registered.
Read the following:
http://wiki.openstack.org/GerritWorkflow
http://wiki.openstack.org/GitCommitMessages
Issue/Bug Tracking
All issues (bug fixes and enhancements) are currently tracked through https://bugs.launchpad.net/heat.
Bug-fixes and minor enhancements (e.g adding missing functionality to existing resources) adding should be tracked through launchpad bugs, major enhancements and new features should be tracked through launchpad blueprints.
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.