opendev/infra-specs
Code Issues Proposed changes
OpenStack Infrastructure Blueprint Repository
36 Commits 1 Branch 0 Tags 4.4 MiB
Python 100%
e2cb246877
Go to file
Thierry Carrez e2cb246877 StoryBoard task branch support 
Spec describing how branch-specific tasks could be implemented in
StoryBoard.

Change-Id: Ib02baca0044894712fd5057718b83ca853c53b5d
2014-12-22 18:12:30 +01:00
doc/source Use the current date for the copyright statement 2014-09-10 16:04:37 -04:00
specs StoryBoard task branch support 2014-12-22 18:12:30 +01: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 Initial commit 2014-06-10 16:25:32 -07: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.