7f2ece4c1b
This moves existing tarball-base settings out of per-release to the overall repository-settings. This is nearly always the same for every release, so it's a little redundant, and having it as an overall setting will cause it to be carried over when running init-series and prevent the need to remember to add it with new releases. Change-Id: I6f5766313a5484653b881cf75f8b3c76a473f3e9 Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com> |
||
|---|---|---|
| deliverables | ||
| doc | ||
| openstack_releases | ||
| templates | ||
| tools | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| bindep.txt | ||
| CONTRIBUTING.rst | ||
| LICENSE | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
| watched_queries.yml | ||
| yamllint.yml | ||
Using This Repository
All official OpenStack software should go through the Release Management team team to produce releases. Exceptions to this rule are granted by the Technical Committee and documented in the openstack/governance repository ('release-management' key in reference/projects.yaml).
This repository is used to track release requests. Releases are managed using groups of "deliverables", made up of individual project repositories sharing a Launchpad group and a version number history. Many deliverables will only have one constituent project repository.
The repository is managed by the Release Management team.
Refer to the reference documentation for more details
Deliverables managed by teams not under OpenStack governance should follow the tagging instructions in the infra manual.