refstack-client/specs
Ghanshyam Mann a2b4ce30b8 Update jobs for interop repos renaming
Interop repos are going under rename from
openstack namespace to osf namespace (Depends-On),
which need update the zuul job to start using the
new location.

Update .gitreview as well.

Disable py27 and py35 jobs, they don't work anymore as is.

Depends-On: https://review.opendev.org/#/c/734669/
Change-Id: Ib6871eaf0735e756f051d14513869fbe7cc6e826
2020-06-13 18:57:48 +02:00
..
newton/approved Add support for new doc PTI jobs 2017-12-18 15:35:32 -08:00
queens/approved Update jobs for interop repos renaming 2020-06-13 18:57:48 +02:00
README.rst Add support for new doc PTI jobs 2017-12-18 15:35:32 -08:00
template.rst Fix a typo in template.rst 2017-03-24 15:04:10 +08:00

Refstack-Client Specifications

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

The layout of this folder is as follows:

specs/<release>/
specs/<release>/approved
specs/<release>/implemented

The lifecycle of a specification

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.

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.

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.

Previously approved specifications

The refstack-client specs directory was created during the Newton cycle. Therefore, the specs approved and implemented prior to the Newton cycle will be saved in the RefStack project.

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

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

$ tox -e docs