Fix some mistakes in README.rst

Change-Id: I554b82a73c7352e84741a2c80f70b355ff93c507
This commit is contained in:
Joshua Hesketh 2015-09-03 20:29:08 +10:00
parent 99c99acaa8
commit d4388e7573

View File

@ -49,7 +49,7 @@ The mechanics of the solution are relatively simple. We maintain a
central list of all the requirements (``global-requirements.txt``) central list of all the requirements (``global-requirements.txt``)
that are allowed in OpenStack projects. This is enforced for that are allowed in OpenStack projects. This is enforced for
``requirements.txt``, ``test-requirements.txt`` and extras defined in ``requirements.txt``, ``test-requirements.txt`` and extras defined in
``setup.cfg``. This is maintained by hand, with changing going through CI. ``setup.cfg``. This is maintained by hand, with changes going through CI.
We also maintain a compiled list of the exact versions, including transitive We also maintain a compiled list of the exact versions, including transitive
dependencies, of packages that are known to work in the OpenStack CI system. dependencies, of packages that are known to work in the OpenStack CI system.
@ -83,14 +83,15 @@ to pin all the libraries to known good versions. ``edit-constraints`` can be
used to unpin a single constraint, and this is done to install libraries from used to unpin a single constraint, and this is done to install libraries from
git. This is the **recommended** way to use devstack. git. This is the **recommended** way to use devstack.
When ``USE_CONSTRAINTS`` is set ``False``, devstack overwrite the ``requirements.txt`` When ``USE_CONSTRAINTS`` is set ``False``, devstack overwrites the
and ``test-requirements.txt`` for **all** installed projects with the versions ``requirements.txt`` and ``test-requirements.txt`` for **all** installed
from ``global-requirements.txt``. Projects that are not in ``projects.txt`` projects with the versions from ``global-requirements.txt``. Projects that are
get 'soft' updates, ones that are get 'hard' updated. This attempts to ensure not in ``projects.txt`` get 'soft' updates, ones that are get 'hard' updated.
that we will get a deterministic set of requirements installed in the test This attempts to ensure that we will get a deterministic set of requirements
system, and it won't be a guessing game based on the last piece of software to installed in the test system, and it won't be a guessing game based on the
be installed. However due to the interactions with transitive dependencies last piece of software to be installed. However due to the interactions with
this doesn't actually deliver what we need, and is **not recommended**. transitive dependencies this doesn't actually deliver what we need, and is
**not recommended**.
Tox Tox
+++ +++
@ -103,11 +104,12 @@ Enforcement in Projects
All projects that have accepted the requirements contract (as listed All projects that have accepted the requirements contract (as listed
in ``projects.txt``) are expected to run a requirements compatibility in ``projects.txt``) are expected to run a requirements compatibility
job that ensures that they can not change any dependencies to versions not job. This job ensures that a project can not change any dependencies to
compatible with ``global-requirements.txt``. It also ensures that those versions not compatible with ``global-requirements.txt``. It also ensures that
projects can't add a requirement that's not already in those projects can not add a requirement that is not already in
``global-requirements.txt``. This job should be proposed to infra at the same ``global-requirements.txt``. This job should be proposed to infra at the same
time as proposing the change in ``openstack/requirements``. time as proposing the change to ``projects.txt`` in
``openstack/requirements``.
Automatic Sync of Accepted Requirements Automatic Sync of Accepted Requirements
--------------------------------------- ---------------------------------------
@ -149,8 +151,8 @@ errors in hard mode (the default) or be ignored in soft mode.
generate-constraints generate-constraints
-------------------- --------------------
Compile a constraints file showing the versions of resulting from installing Compile a constraints file showing the versions resulting from installing all
all of ``global-requirements.txt``:: of ``global-requirements.txt``::
generate-constraints -p /usr/bin/python2.7 -p /usr/bin/python3.4 \ generate-constraints -p /usr/bin/python2.7 -p /usr/bin/python3.4 \
-b blacklist.txt -r global-requirements.txt > new-constraints.txt -b blacklist.txt -r global-requirements.txt > new-constraints.txt
@ -172,7 +174,7 @@ Look at the `Review Guidelines` and make sure your change meets them.
All changes to ``global-requirements.txt`` may dramatically alter the contents All changes to ``global-requirements.txt`` may dramatically alter the contents
of ``upper-constraints.txt`` due to adding or removing transitive of ``upper-constraints.txt`` due to adding or removing transitive
dependencies. As such you should always generate a diff against the current dependencies. As such you should always generate a diff against the current
merged constraints, otherwise your change may fail if it is incompatible wit merged constraints, otherwise your change may fail if it is incompatible with
the current tested constraints. the current tested constraints.
Regenerating involves five steps. Regenerating involves five steps.
@ -203,7 +205,7 @@ Review Guidelines
================= =================
There are a set of questions that every reviewer should ask on any There are a set of questions that every reviewer should ask on any
proposed requirements change. Proposers can make reviews easier by proposed requirements change. Proposers can make reviewing easier by
including the answers to these questions in the commit message for including the answers to these questions in the commit message for
their change. their change.