refstack/specs
david db373bc05e small change removing need for ui for this feature.
from now on all testing will happen from tcup. no local test path needs to exist.

Change-Id: Ibfebcb67b5eb307b670794af07e31fe3f9f0dd0f
2014-07-05 14:42:41 -07:00
..
approved small change removing need for ui for this feature. 2014-07-05 14:42:41 -07:00
proposed Use keystone uuid with cloud id 2014-06-26 13:23:38 -05:00
README.rst Remove executable flags 2014-05-13 16:32:01 +02:00
template.rst removed creative commons lic from template 2014-06-10 14:19:11 -07:00

Refstack Specifications

This folder is used to hold design specifications for additions to the Refstack project. Reviews of the specs are done in gerrit, using a similar workflow to how we review and merge changes to the code itself.

Specifications are proposed by adding an .rst file to the specs/proposed directory and posting it for review. Not all approved blueprints will get fully implemented. You can find an example spec in /specs/template.rst.

When a spec has passed the review process and discussions in our weekly meetings it will be moved to 'specs/approved/'. At that time the blueprint will be marked as approved and assigned to someone.

Once a spec has been fully implemented, meaning a patch has landed that references the blueprint, it will be moved again to 'specs/completed'.

Prior to April 2014, this method was not used for spec reviews. Prior reviews were completed entirely through Launchpad blueprints:

http://blueprints.launchpad.net/refstack

Please note, Launchpad blueprints are still used for tracking the current status of blueprints. For more information, see:

https://wiki.openstack.org/wiki/Blueprints

For more information about working with gerrit, see:

https://wiki.openstack.org/wiki/Gerrit_Workflow

To validate that the specification is syntactically correct (i.e. get more confidence in the Jenkins result), please execute the following command:

$ tox