Re-organize the RefStack specs directory.

Change-Id: I02da57c2b7d888ae49bd4f96ba8fb46016d16e7d
This commit is contained in:
cdiep 2015-12-08 10:44:57 -08:00
parent b787b408e5
commit 3de1984dee
15 changed files with 37 additions and 17 deletions

View File

@ -1,34 +1,54 @@
================================== =======================
Refstack Specifications Refstack Specifications
================================== =======================
This folder is used to hold design specifications for additions 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 to the RefStack project. Reviews of the specs are done in gerrit, using a
workflow to how we review and merge changes to the code itself. 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`. The layout of this folder is as follows::
When a spec has passed the review process and discussions in our weekly meetings it will specs/<release>/
be moved to 'specs/approved/'. At that time the blueprint will be marked as approved and assigned to someone. specs/<release>/approved
specs/<release>/implemented
Once a spec has been fully implemented, meaning a patch has landed that references the blueprint, it will be moved again to 'specs/completed'. The lifecycle of a specification
--------------------------------
Prior to April 2014, this method was not used for spec Specifications are proposed by adding an .rst file to the
reviews. Prior reviews were completed entirely through Launchpad ``specs/<release>/approved`` directory and posting it for review. You can
blueprints:: find an example specification in ``/specs/template.rst``.
http://blueprints.launchpad.net/refstack Once a specification has been fully implemented, meaning a patch has landed,
it will be moved to the ``implemented`` directory and the corresponding
blueprint will be marked as complete.
Please note, Launchpad blueprints are still used for tracking the `Specifications are only approved for a single release`. If a specification
current status of blueprints. For more information, see:: was previously approved but not implemented (or not completely implemented),
then the specification needs to be re-proposed by copying (not move) it to
the right directory for the current release.
https://wiki.openstack.org/wiki/Blueprints Previously approved specifications
----------------------------------
The RefStack specs directory was re-structured during the Mitaka cycle.
Therefore, the specs approved and implemented prior to the Mitaka cycle will be
saved in the ``specs/prior/`` directories.
Others
------
Please note, Launchpad blueprints are still used for tracking the status of the
blueprints. For more information, see::
https://wiki.openstack.org/wiki/Blueprints
https://blueprints.launchpad.net/refstack
For more information about working with gerrit, see:: For more information about working with gerrit, see::
http://docs.openstack.org/infra/manual/developers.html#development-workflow http://docs.openstack.org/infra/manual/developers.html#development-workflow
To validate that the specification is syntactically correct (i.e. get more To validate that the specification is syntactically correct (i.e. get more
confidence in the Jenkins result), please execute the following command:: confidence in the Jenkins result), please execute the following command::
$ tox $ tox