6590b5cc21
Add collectd-ceilometer specific contrib information - What needs to be included in a feature? - How to add a reno entry Change-Id: I91cf5af30eb0e26695dffd374f796023dd8af099
82 lines
2.7 KiB
ReStructuredText
82 lines
2.7 KiB
ReStructuredText
Contributing to Openstack
|
|
=========================
|
|
|
|
If you would like to contribute to the development of OpenStack, you must
|
|
follow the steps in this page:
|
|
|
|
http://docs.openstack.org/infra/manual/developers.html
|
|
|
|
If you already have a good understanding of how the system works and your
|
|
OpenStack accounts are set up, you can skip to the development workflow
|
|
section of this documentation to learn how changes to OpenStack should be
|
|
submitted for review via the Gerrit tool:
|
|
|
|
http://docs.openstack.org/infra/manual/developers.html#development-workflow
|
|
|
|
Pull requests submitted through GitHub will be ignored.
|
|
|
|
Bugs should be filed on Launchpad, not GitHub:
|
|
|
|
https://bugs.launchpad.net/collectd-ceilometer-plugin
|
|
|
|
Contributing to collectd-ceilometer-plugin
|
|
==========================================
|
|
|
|
As well as following the OpenStack contribution guidelines, there are a few
|
|
guidelines that should be observed for this project.
|
|
|
|
Blueprints
|
|
----------
|
|
Blueprints are generally not required for features. A bug should be opened in
|
|
launchpad instead and tagged as "rfe".
|
|
|
|
|
|
Feature development
|
|
-------------------
|
|
Each feature should consist of a number of components (below), which can be submitted
|
|
in separate, dependant patches.
|
|
|
|
Each patch should function independently, and should work even if the
|
|
following patches are not applied.
|
|
|
|
The patches should include the following:
|
|
|
|
- Feature enabling code
|
|
- For larger features, there might be several smaller patches.
|
|
|
|
- Unit tests
|
|
- Tests should be included with the relevant feature code.
|
|
|
|
- Documentation
|
|
- How does the feature work?
|
|
- How do you configure this feature when installing a) manually and b) using
|
|
devstack?
|
|
- What configuration options were introduced/changed?
|
|
- Examples for particular scenarios should be included in the
|
|
doc/source/examples/ directory.
|
|
- Updates to individual config options should be included in doc/source/usage.rst.
|
|
|
|
- Deployment code
|
|
- At a minimum, deployment code for devstack, including
|
|
any relevant config options, should be added.
|
|
- Deployment code includes any changes to the given configurations.
|
|
|
|
- Release note
|
|
- A reno entry needs to be included for every change:
|
|
http://docs.openstack.org/developer/reno/usage.html#creating-new-release-notes
|
|
|
|
|
|
Bug Fixes
|
|
---------
|
|
A bug fix will typically be a single patch, with any relevant changes to
|
|
documantation, configuration, etc included.
|
|
|
|
Release notes should be created using the bug number in the following way::
|
|
reno new bug-123456
|
|
|
|
Release notes should reference the bug number and have a brief description
|
|
of the bug e.g.::
|
|
critical|security|fixes:
|
|
- Fixed bug #123456: Authentication token now automatically renews after
|
|
expiry.
|