akanda/specs
Adam Gandelman 3bcb84b512 Plan for first iteration of CI gate infrastructure
This outlines some preliminary thoughts on upstream CI testing
for Akanda projects.

Implements blueprint ci-updates

Change-Id: I64b4d0b9f34e6e00b7ba6abcfdc1dd9408c3d13b
2015-04-29 13:21:20 -07:00
..
kilo Plan for first iteration of CI gate infrastructure 2015-04-29 13:21:20 -07:00
liberty Create akanda specs structure 2015-04-27 15:43:53 -07:00
README.rst Create akanda specs structure 2015-04-27 15:43:53 -07:00
skeleton.rst Create akanda specs structure 2015-04-27 15:43:53 -07:00
template.tst Create akanda specs structure 2015-04-27 15:43:53 -07:00

OpenStack Akanda Specifications

This directory structure is used to hold approved design specifications for additions to the Akanda 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 repository is:

specs/<release>/

You can find an example spec in specs/template.rst. A skeleton that contains all the sections required for a spec file is located in specs/skeleton.rst and can be copied, then filled in with the details of a new blueprint for convenience.

Specifications are proposed for a given release by adding them to the specs/<release> directory and posting it for review. The implementation status of a blueprint for a given release can be found by looking at the blueprint in launchpad. Not all approved blueprints will get fully implemented.

Specifications have to be re-proposed for every release. The review may be quick, but even if something was previously approved, it should be re-reviewed to make sure it still makes sense as written.

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

https://wiki.openstack.org/wiki/Blueprints
http://blueprints.launchpad.net/akanda

For more information about working with gerrit, see:

http://docs.openstack.org/infra/manual/developers.html#development-workflow