opendev
/
infra-specs
Code Issues Proposed changes
OpenStack Infrastructure Blueprint Repository
55 Commits 1 Branch 0 Tags 4.4 MiB
Python 100%
Go to file
Jenkins f0041f41e6 Merge "Use the correct project name" 2014-12-22 20:15:14 +00:00
doc/source Adds an implemented directory 2014-12-10 15:44:29 -07:00
specs Merge "Use the correct project name" 2014-12-22 20:15:14 +00: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 copyright placeholder to template 2014-07-31 21:05:21 +00: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.