openstack
/
qa-specs
Code Issues Proposed changes
OpenStack QA Specifications
7 Commits 1 Branch 0 Tags 3.1 MiB
Python 100%
Go to file
Matthew Treinish cde37db455 Add a license file 
This commit adds a license file to qa-specs which was missing. The
license is set to CC-BY per the discussion on the legal-discuss
mailing list:

http://lists.openstack.org/pipermail/legal-discuss/2014-March/000201.html

Change-Id: I928118311df1e1f91b8768bbcc679d86a59c5dd0
 		2014-03-25 18:27:36 -04:00
doc/source Add sphinx support to qa-specs repo 2014-03-24 13:36:43 -04:00
specs Update process flow 2014-03-17 11:10:25 -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 Add sphinx support to qa-specs repo 2014-03-24 13:36:43 -04:00
setup.py Add sphinx support to qa-specs repo 2014-03-24 13:36:43 -04:00
tox.ini Add sphinx support to qa-specs repo 2014-03-24 13:36:43 -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.