openstack
/
qa-specs
Code Issues Proposed changes
OpenStack QA Specifications
15 Commits 1 Branch 0 Tags 3.1 MiB
Python 100%
Go to file
Matthew Treinish fde3118924 Make build_sphinx warning proof 
This commit makes changes to the rst files so sphinx will not throw any
warnings. The implemented section of the index is removed, we can add
it back when a specification is implemented and we move it into that
directory.

Change-Id: I09f813623c8bdfd830f73592aac6cf57abe87741
 		2014-04-06 12:20:51 -04:00
doc/source Make build_sphinx warning proof 2014-04-06 12:20:51 -04:00
specs Add spec for bp:add-service-tags 2014-03-27 15:21:21 -04:00
.gitignore Add sphinx support to qa-specs repo 2014-03-24 13:36:43 -04:00
.gitreview Added .gitreview 2014-03-14 23:10:06 +00:00
LICENSE Add a license file 2014-03-25 18:27:36 -04:00
README.rst Update process flow 2014-03-17 11:10:25 -04:00
requirements.txt Add sphinx support to qa-specs repo 2014-03-24 13:36:43 -04:00
setup.cfg Mirror tox and sphinx fixes from nova-specs repo 2014-04-01 13:13:48 -04:00
setup.py Add sphinx support to qa-specs repo 2014-03-24 13:36:43 -04:00
template.rst Make build_sphinx warning proof 2014-04-06 12:20:51 -04:00
tox.ini Mirror tox and sphinx fixes from nova-specs repo 2014-04-01 13:13:48 -04:00

README.rst

QA Specs Repository

This is a git repository for doing design review on QA enhancements as part of the OpenStack program. 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 blueprint stub in tempest blueprint repository
  2. Propose review to qa-specs repository (ensure bp:blueprint_name is in the commit message
  3. Link Read the full specification to the gerrit address of the spec
  4. Bring forward the proposed item to the openstack-qa meeting for summary
  5. Review happens on proposal by qa-core members, and others
  6. Iterate until review is Approved or Rejected

Once a Review is Approved...

  1. Update blueprint, Copy summary text of blueprint to there
  2. Link Read the full specification to the git address of the spec
  3. Profit!

Revisiting Specs

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 spec 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.