RETIRED, OpenStack Storage (Swift) Specifications
Go to file
Shiva Chaitanya 08226f79b6 Swift tiering specification
Change-Id: Id9b39b5b856da9c37cc37e6882fef814af81f540
2015-08-04 19:19:16 +00:00
doc/source updated docs on specs workflow 2014-11-12 11:34:39 +00:00
specs Swift tiering specification 2015-08-04 19:19:16 +00:00
.coveragerc Add the initial specs framework 2014-06-25 17:49:57 -07:00
.gitignore Add the initial specs framework 2014-06-25 17:49:57 -07:00
.gitreview Add the initial specs framework 2014-06-25 17:49:57 -07:00
.mailmap Add the initial specs framework 2014-06-25 17:49:57 -07:00
.testr.conf Add the initial specs framework 2014-06-25 17:49:57 -07:00
CONTRIBUTING.rst Workflow documentation is now in infra-manual 2014-12-05 03:30:41 +00:00
LICENSE Add the initial specs framework 2014-06-25 17:49:57 -07:00
MANIFEST.in Add the initial specs framework 2014-06-25 17:49:57 -07:00
README.rst updated docs on specs workflow 2014-11-12 11:34:39 +00:00
requirements.txt Add RSS feed 2014-09-26 16:27:37 -04:00
setup.cfg Add the initial specs framework 2014-06-25 17:49:57 -07:00
setup.py Add the initial specs framework 2014-06-25 17:49:57 -07:00
template.rst Add the initial specs framework 2014-06-25 17:49:57 -07:00
test-requirements.txt Add the initial specs framework 2014-06-25 17:49:57 -07:00
tox.ini Add the initial specs framework 2014-06-25 17:49:57 -07:00

README.rst

Swift Specs Repository

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

Repository Structure

The structure of the repository is as follows:

specs/
    done/
    in_progress/

Implemented specs will be moved to done-directory once the associated code has landed.

The Flow of an Idea from your Head to Implementation

First propose a spec to the in_progress directory so that it can be reviewed. Reviewers adding a positive +1/+2 review in gerrit are promising that they will review the code when it is proposed. Spec documents should be approved and merged as soon as possible, and spec documents in the in_progress directory can be updated as often as needed. Iterate on it.

  1. Have an idea
  2. Propose a spec
  3. Reviewers review the spec. As soon as 2 core reviewers like something, merge it. Iterate on the spec as often as needed, and keep it updated.
  4. Once there is agreement on the spec, write the code.
  5. As the code changes during review, keep the spec updated as needed.
  6. Once the code lands (with all necessary tests and docs), the spec can be moved to the done directory. If a feature needs a spec, it needs docs, and the docs must land before or with the feature (not after).

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.