Browse Source

Re-organize the RefStack specs directory.

Change-Id: I02da57c2b7d888ae49bd4f96ba8fb46016d16e7d
changes/06/254906/2
cdiep 5 years ago
parent
commit
3de1984dee
15 changed files with 37 additions and 17 deletions
  1. +37
    -17
      specs/README.rst
  2. +0
    -0
      specs/mitaka/implemented/rsa-key-existence-check.rst
  3. +0
    -0
      specs/prior/approved/ability_to_upload_a_complete_tempest_config.rst
  4. +0
    -0
      specs/prior/approved/refstack-org-defcore-reports.rst
  5. +0
    -0
      specs/prior/approved/refstack-org-gearman-tester.rst
  6. +0
    -0
      specs/prior/approved/refstack-org-result-visualization.rst
  7. +0
    -0
      specs/prior/approved/refstack-org-tcup-base.rst
  8. +0
    -0
      specs/prior/implemented/api-v1.md
  9. +0
    -0
      specs/prior/implemented/coretest-testid.rst
  10. +0
    -0
      specs/prior/implemented/identify-code-to-deprecate.rst
  11. +0
    -0
      specs/prior/implemented/refstack-org-api-cloud-uuid.rst
  12. +0
    -0
      specs/prior/implemented/refstack-org-test-result-json-schema.rst
  13. +0
    -0
      specs/prior/implemented/seperate_refstack_tester_from_refstack.rst
  14. +0
    -0
      specs/prior/implemented/simplify-uploads-by-only-sending-pass-results.rst
  15. +0
    -0
      specs/prior/implemented/test-record-api.rst

+ 37
- 17
specs/README.rst View File

@ -1,34 +1,54 @@
==================================
=======================
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.
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`.
The layout of this folder is as follows::
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.
specs/<release>/
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
reviews. Prior reviews were completed entirely through Launchpad
blueprints::
Specifications are proposed by adding an .rst file to the
``specs/<release>/approved`` directory and posting it for review. You can
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
current status of blueprints. For more information, see::
`Specifications are only approved for a single release`. If a specification
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::
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
confidence in the Jenkins result), please execute the following command::
$ tox
$ tox

specs/proposed/rsa-key-existence-check.rst → specs/mitaka/implemented/rsa-key-existence-check.rst View File


specs/approved/ability_to_upload_a_complete_tempest_config.rst → specs/prior/approved/ability_to_upload_a_complete_tempest_config.rst View File


specs/proposed/refstack-org-defcore-reports.rst → specs/prior/approved/refstack-org-defcore-reports.rst View File


specs/proposed/refstack-org-gearman-tester.rst → specs/prior/approved/refstack-org-gearman-tester.rst View File


specs/proposed/refstack-org-result-visualization.rst → specs/prior/approved/refstack-org-result-visualization.rst View File


specs/proposed/refstack-org-tcup-base.rst → specs/prior/approved/refstack-org-tcup-base.rst View File


specs/approved/api-v1.md → specs/prior/implemented/api-v1.md View File


specs/proposed/coretest-testid.rst → specs/prior/implemented/coretest-testid.rst View File


specs/approved/identify-code-to-deprecate.rst → specs/prior/implemented/identify-code-to-deprecate.rst View File


specs/proposed/refstack-org-api-cloud-uuid.rst → specs/prior/implemented/refstack-org-api-cloud-uuid.rst View File


specs/approved/refstack-org-test-result-json-schema.rst → specs/prior/implemented/refstack-org-test-result-json-schema.rst View File


specs/approved/seperate_refstack_tester_from_refstack.rst → specs/prior/implemented/seperate_refstack_tester_from_refstack.rst View File


specs/approved/simplify-uploads-by-only-sending-pass-results.rst → specs/prior/implemented/simplify-uploads-by-only-sending-pass-results.rst View File


specs/proposed/test-record-api.rst → specs/prior/implemented/test-record-api.rst View File


Loading…
Cancel
Save