OpenDev Migration Patch
This commit was bulk generated and pushed by the OpenDev sysadmins as a part of the Git hosting and code review systems migration detailed in these mailing list posts: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004920.html Attempts have been made to correct repository namespaces and hostnames based on simple pattern matching, but it's possible some were updated incorrectly or missed entirely. Please reach out to us via the contact information listed at https://opendev.org/ with any questions you may have.
|1 month ago|
|doc/source||3 years ago|
|specs||3 years ago|
|.coveragerc||3 years ago|
|.gitignore||4 years ago|
|.gitreview||1 month ago|
|.mailmap||4 years ago|
|.testr.conf||4 years ago|
|CONTRIBUTING.rst||4 years ago|
|LICENSE||4 years ago|
|MANIFEST.in||4 years ago|
|README.rst||2 years ago|
|requirements.txt||4 years ago|
|setup.cfg||4 years ago|
|setup.py||4 years ago|
|template.rst||4 years ago|
|test-requirements.txt||4 years ago|
|tox.ini||3 years ago|
Documents in this repo are a collection of ideas. They are not necessarily a formal design for a feature, nor are they docs for a feature, nor are they a roadmap for future features.
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.
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.
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.
donedirectory. If a feature needs a spec, it needs docs, and the docs must land before or with the feature (not after).
Naturally you'll want clarifications about the way a spec is written. To ask questions, propose a patch to the spec (via the normal patch proposal tools) with your question or your understanding of the confusing part. That will raise the issue in a patch review and allow everyone to answer or comment.
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.