Browse Source

Merge "Cleanup specs folder"

Zuul 1 month ago
parent
commit
5e55719280
3 changed files with 35 additions and 47 deletions
  1. 0
    0
      doc/source/specs/COPYME
  2. 35
    14
      doc/source/specs/index.rst
  3. 0
    33
      doc/source/specs/specifications.rst

doc/source/specs/template.rst → doc/source/specs/COPYME View File


+ 35
- 14
doc/source/specs/index.rst View File

@@ -1,19 +1,40 @@
1
-Specifications
2
-==============
1
+Project Specifications
2
+======================
3 3
 
4
-Contents:
4
+Specifications in this repository represent a consensus on the topics covered
5
+within.  They should be considered a mandate on the path forward with regards
6
+to the content on which they are drafted.
7
+
8
+Here is a list of the current specs:
5 9
 
6 10
 .. toctree::
7 11
    :maxdepth: 1
12
+   :glob:
13
+
14
+   *
15
+
16
+Specifications Purpose
17
+----------------------
18
+
19
+A specification should precede any broad-reaching technical changes or proposals
20
+to OpenStack-Helm.  Examples of changes requiring a specification include:  a
21
+standard format to the values.yaml files, multiple backend support for neutron,
22
+and the approach for logging and monitoring in OpenStack-Helm.  Some additional
23
+features will not need an accompanying specification, but may be tied back to an
24
+existing specification.  An example of this would be introducing a service in
25
+OpenStack-Helm that could be included under the scope of a specification already
26
+drafted and approved.
27
+
28
+Specifications Process
29
+----------------------
30
+
31
+Before drafting a specification, a blueprint should be filed in Storyboard_
32
+along with any dependencies the blueprint requires.  Once the blueprint has been
33
+registered, submit the specification as a patch set to the specs/ directory
34
+using the supplied template.
35
+
36
+More information about the blueprint + specification lifecycle can be found
37
+here_.
8 38
 
9
-   developer-environment.rst
10
-   osh-lma-stack.rst
11
-   specifications.rst
12
-   template.rst
13
-   neutron-multiple-sdns.rst
14
-   nginx-sidecar.rst
15
-   support-linux-bridge-on-neutron.rst
16
-   fluentbit-fluentd-architecture.rst
17
-   osh-1.0-requirements.rst
18
-   values-ordering.rst
19
-   tenant-ceph.rst
39
+.. _Storyboard: https://storyboard.openstack.org/#!/project_group/64
40
+.. _here: https://wiki.openstack.org/wiki/Blueprints#Blueprints_and_Specs

+ 0
- 33
doc/source/specs/specifications.rst View File

@@ -1,33 +0,0 @@
1
-=====================
2
-Project Specfications
3
-=====================
4
-
5
-Specifications in this repository represent a consensus on the topics covered
6
-within.  They should be considered a mandate on the path forward with regards
7
-to the content on which they are drafted.
8
-
9
-Purpose
10
--------
11
-
12
-A specification should precede any broad-reaching technical changes or proposals
13
-to OpenStack-Helm.  Examples of changes requiring a specification include:  a
14
-standard format to the values.yaml files, multiple backend support for neutron,
15
-and the approach for logging and monitoring in OpenStack-Helm.  Some additional
16
-features will not need an accompanying specification, but may be tied back to an
17
-existing specification.  An example of this would be introducing a service in
18
-OpenStack-Helm that could be included under the scope of a specification already
19
-drafted and approved.
20
-
21
-Process
22
--------
23
-
24
-Before drafting a specification, a blueprint should be filed in Storyboard_
25
-along with any dependencies the blueprint requires.  Once the blueprint has been
26
-registered, submit the specification as a patch set to the specs/ directory
27
-using the supplied template.
28
-
29
-More information about the blueprint + specification lifecycle can be found
30
-here_.
31
-
32
-.. _Storyboard: https://storyboard.openstack.org/#!/project_group/64
33
-.. _here: https://wiki.openstack.org/wiki/Blueprints#Blueprints_and_Specs

Loading…
Cancel
Save