Don't move specs from approved directory

When specs are approved but not yet implemented, they reside in
specs/approved. After implementation, we have been moving them to
specs/<release>-implemented. Which means that any links to specs
in specs/approved are broken.

This patch leaves the specs in specs/approved, and adds a new
specs/not-implemented directory that contains soft links to all the
approved-but-not-yet-implemented specs that reside in specs/approved.
For specs that were implemented, e.g. in release 4.3, a specs/4.3
directory is created with soft links to the implemented specs (that still
reside in specs/approved).

Since we are using links to files, the specs cannot have labels
because sphinx warns of duplicate labels.

Change-Id: Icd81d68cec4bbfaa3b20e370ba1b31edb32ae1d1
This commit is contained in:
Ruby Loo 2015-12-15 17:31:35 +00:00
parent 6d9256c96d
commit 1b303b8142
25 changed files with 62 additions and 11 deletions

View File

@ -10,19 +10,27 @@ how we review and merge changes to the code itself.
The layout of this repository is::
specs/approved/
specs/backlog`/
specs/<cycle>-implemented/
specs/backlog/
specs/not-implemented/
specs/<release>/
specs/<juno|kilo|liberty>-implemented/
There are also placeholder directories for old links that have been moved.
Specifications must follow the template which can be found at
`doc/source/specs/template.rst`.
Specifications are proposed by adding them to the `specs/approved` directory
and posting it for review. When a spec is fully implemented, it should be
moved to specs/<cycle>-implemented. Not all approved blueprints will get
Specifications are proposed by adding them to the `specs/approved` directory,
adding a soft link to it from the `specs/not-implemented` directory, and
posting it for review. When a specification is fully implemented, the link in
`specs/not-implemented` directory should be moved to the appropriate
`specs/<release>` directory. Not all approved specifications will get
fully implemented.
Starting with the Mitaka development cycle, all approved specifications
(implemented and not-implemented) will reside in the `specs/approved`
directory.
Prior to the Juno development cycle, this repository was not used for spec
reviews. Reviews prior to Juno were completed entirely through Launchpad
blueprints::

View File

@ -37,7 +37,7 @@ implemented:
:glob:
:maxdepth: 1
specs/approved/*
specs/not-implemented/*
Back-log of ideas
@ -61,6 +61,15 @@ development cycles in which they were completed.
Mitaka
------
4.3
~~~
.. toctree::
:glob:
:maxdepth: 1
specs/4.3/*
Liberty
-------
@ -116,6 +125,19 @@ Juno
specs/kilo/*
specs/juno/*
..
----------------
As of the start of the Mitaka development cycle, all approved specs
will reside in specs/approved (not-yet-implemented as well as implemented
specs). The files will not be moved (we hope). Instead, we will create
directories with links to these files. The specs/approved directory
will be hidden.
.. toctree::
:glob:
:hidden:
specs/approved/*
==================
Indices and tables

View File

@ -0,0 +1 @@
../approved/iscsi-deploy-in-band-cleaning.rst

View File

@ -0,0 +1 @@
../approved/new-ironic-driver-for-oneview.rst

View File

@ -0,0 +1 @@
../approved/radosgw-temp-url.rst

View File

@ -52,7 +52,8 @@ The main differences will be:
* operators will be able to initiate a manual clean via the modified API
to set the nodes's provision state. Details are described in the
:ref:`ProvisionCleanAPI` section.
`PUT .../states/provision <#put-v1-nodes-node-ident-states-provision>`_
section below.
* A manual clean step might need some arguments to be specified. (This might
be useful for future automated steps too.) To support this, the
@ -72,7 +73,8 @@ The main differences will be:
include any arguments that can be passed to the clean step.
* operators will be able to get a list of possible steps via an API. The
:ref:`CleanStepsAPI` section provides more information.
`GET .../cleaning/steps <#get-nodes-node-ident-cleaning-steps>`_ section
below provides more information.
* similar to executing automated clean steps, when the conductor attempts to
execute a manual clean step, it will call execute_clean_step() on the driver
@ -121,8 +123,6 @@ This:
REST API impact
---------------
.. _ProvisionCleanAPI:
PUT /v1/nodes/<node_ident>/states/provision
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -173,7 +173,6 @@ be put in CLEANFAIL provision state with an appropriate error message.
A new API version is needed to support this.
.. _CleanStepsAPI:
GET /nodes/<node_ident>/cleaning/steps
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

View File

@ -0,0 +1 @@
../approved/add-pluggable-metrics-backend-for-ironic-and-ipa.rst

View File

@ -0,0 +1 @@
../approved/agent-image-proxy.rst

View File

@ -0,0 +1 @@
../approved/bare-metal-trust-using-intel-txt.rst

View File

@ -0,0 +1 @@
../approved/cisco-ucs-hw-inspection.rst

View File

@ -0,0 +1 @@
../approved/futurist.rst

View File

@ -0,0 +1 @@
../approved/inband-raid-configuration.rst

View File

@ -0,0 +1 @@
../approved/ipxe-dynamic-config.rst

View File

@ -0,0 +1 @@
../approved/ipxe-swift-tempurls.rst

View File

@ -0,0 +1 @@
../approved/ironic-generic-raid-interface.rst

View File

@ -0,0 +1 @@
../approved/ironic-ml2-integration.rst

View File

@ -0,0 +1 @@
../approved/manual-cleaning.rst

View File

@ -0,0 +1 @@
../approved/network-provider.rst

View File

@ -0,0 +1 @@
../approved/nodes-tagging.rst

View File

@ -0,0 +1 @@
../approved/notifications.rst

View File

@ -0,0 +1 @@
../approved/override-pxe-options-via-glance-property.rst

View File

@ -0,0 +1 @@
../approved/petitboot-boot-driver.rst

View File

@ -0,0 +1 @@
../approved/ssh-console-support.rst

View File

@ -0,0 +1 @@
../approved/third-party-ci.rst

View File

@ -0,0 +1 @@
../approved/version-caching.rst