OpenDev Manual
Go to file
OpenDev Sysadmins eafd8722cd 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.
2019-04-19 19:42:46 +00:00
doc/source Improve the details about settings i18n for new repos 2019-03-26 10:37:29 +01:00
.gitignore Add ChangeLog and AUTHORS to .gitignore 2015-05-13 16:20:27 -07:00
.gitreview OpenDev Migration Patch 2019-04-19 19:42:46 +00:00
LICENSE Initial commit 2014-05-26 20:25:48 -04:00
README.rst Add terminology notes to README 2015-08-07 10:31:33 -07:00
requirements.txt Use sidebar from openstackdocstheme 1.17 2017-09-12 20:16:49 +02:00
setup.cfg Revert "Change openstack-infra to openstack-discuss" 2018-12-04 16:05:47 +00:00
setup.py Update sphinx version 2016-10-10 21:38:41 +02:00
tox.ini Fix yaml snippet for sphinx for python3 2018-01-08 08:59:20 -06:00

README.rst

OpenStack Project Infrastructure Manual

To build the manual, execute the following command:

$ tox

After running tox, the documentation will be available for viewing in HTML format in the doc/build/ directory.

Terminology

A note on terminology use in the manual:

This is a manual that describes how to use the OpenStack project infrastructure. The OpenStack project, and the Technical Committee (TC) in particular, from time to time uses words such as "project", "team", "program", "repository", etc. to help classify how it organizes the OpenStack project from an administrative point of view. This manual is in service of OpenStack, but does so primarily by documenting how developers and project drivers can use the infrastructure to accomplish their work. While the TC may change its terms from time to time, it is not necessary for us to change all of the terminology in this manual to match. We should strive for consistent terminology that matches what developers and our tooling use. When we describe specific TC-related processes, we should use the current TC terminology to avoid confusion.

Generally speaking these terms should be used as follows:

Project: The overall idea that there is a bunch of people working on a bunch of code/text/etc. It can also refer to that actual collection of code/text/etc (for instance, a project can be bundled up into a tarball, and extracted into a directory). When a tool interacts with that collection of code/text/etc, it interacts with the project (even if it does so via the mechanism of git).

Repository: There are times when one needs to refer to the actual source code management system of a project, that is, "git", and the actual technical implementations of that SCM. In those cases where it is important to distinguish the actual attributes of the SCM from the project, it is useful to use the word "repository".