OpenStack Infrastructure Blueprint Repository
Go to file
James Polley 23da7b76ed Seperate paragraphs in zuul_split spec
The text is a little hard to read at present as the `Proposed Change`
section has one very large paragraph which expresses several ideas.

I've added a paragraph break at one point that seemed to be intended as
a paragraph break. It could possibly benefit from some more but the
original author's intent isn't as clear so I've left them alone.

Change-Id: I2821b5ed33c9aa1af46ce7f45899dbb259f5ad41
2015-04-09 15:54:49 +10:00
doc/source Adds an implemented directory 2014-12-10 15:44:29 -07:00
specs Seperate paragraphs in zuul_split spec 2015-04-09 15:54:49 +10:00
.coveragerc Initial commit 2014-06-10 16:25:32 -07:00
.gitignore Initial commit 2014-06-10 16:25:32 -07:00
.gitreview Added .gitreview 2014-05-20 16:36:13 +00:00
.mailmap Initial commit 2014-06-10 16:25:32 -07:00
.testr.conf Initial commit 2014-06-10 16:25:32 -07:00
CONTRIBUTING.rst Workflow documentation is now in infra-manual 2014-12-05 11:56:28 -08:00
LICENSE Initial commit 2014-06-10 16:25:32 -07:00
MANIFEST.in Initial commit 2014-06-10 16:25:32 -07:00
README.rst Initial commit 2014-06-10 16:25:32 -07:00
requirements.txt Add RSS feed 2014-09-10 16:04:35 -04:00
setup.cfg Initial commit 2014-06-10 16:25:32 -07:00
setup.py Initial commit 2014-06-10 16:25:32 -07:00
template.rst Add Gerrit Topic to the spec template 2015-03-03 11:18:10 -08:00
test-requirements.txt Initial commit 2014-06-10 16:25:32 -07:00
tox.ini Initial commit 2014-06-10 16:25:32 -07:00

README.rst

Infra Specs Repository

This is a git repository for doing design review on enhancements to the OpenStack Project Infrastructure. This provides an ability to ensure that everyone has signed off on the approach to solving a problem early on.

Repository Structure

The expected structure of the respository is as follows:

specs/
    implemented/

Expected Work Flow

  1. Create a story in StoryBoard with a task affecting the infra-specs project.
  2. Propose review to infra-specs repository (ensure Story:<story number> is in the commit message).
  3. Leave a comment with the Gerrit address of the specification.
  4. Bring forward the proposed item to the infra meeting for summary.
  5. Review happens on proposal by infra-core members and others.
  6. Iterate until review is Approved or Rejected.

Once a specification is Approved...

  1. Update story, copy summary text of specification to there.
  2. Leave a comment to the git address of the specification.

Revisiting Specifications

We don't always get everything right the first time. If we realize we need to revisit a specification because something changed, either we now know more, or a new idea came in which we should embrace, we'll manage this by proposing an update to the specification in question.

Learn As We Go

This is a new way of attempting things, so we're going to be low in process to begin with to figure out where we go from here. Expect some early flexibility in evolving this effort over time.