Re-organize the RefStack specs directory.
Change-Id: I02da57c2b7d888ae49bd4f96ba8fb46016d16e7d
This commit is contained in:
parent
b787b408e5
commit
3de1984dee
@ -1,28 +1,48 @@
|
|||||||
==================================
|
=======================
|
||||||
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.
|
||||||
|
|
||||||
|
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://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::
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user