[openstack-dev] [all][requirements] Refresher on how to use global requirements process
Davanum Srinivas
davanum at gmail.com
Wed May 18 11:43:19 UTC 2016
Team,
Here's a primer on how to make sure your project is subject requirements
process.
Step #1: Submit a patch to this file at the following locations to
add a "check-requirements" job (Example is for Monasca)
http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml#n7386
http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml#n7414
This step adds a CI job to your review process, when the
requirements.txt in your
project differs from the one in global-requirements.txt it will complain loudly
and fail your review. This ensures that your project requirements.txt will not
have anything other than the entries in global-requirements.txt
Step #2: Submit a patch to this file
http://git.openstack.org/cgit/openstack/requirements/tree/projects.txt
This step ensures that when the nightly proposal bot/script runs, it will
create a fresh review in your project queue with any changes that were made
to global-requirements.txt.
We won't accept a patch for projects.txt in step #2 without seeing a review
for step #2. Once you have Step #1 and Step #2, your project is essentially
subscribed to the global requirements process. If we break you, then we
revert stuff or work with you to move forward. If you see the list of projects
in projects.txt, essentially we are guaranteeing that we won't break
any of them.
Step #3, is adding your python packages to global-requirements.txt. If a
project has done Step #1 and #2, the requirements team is obligated to revert
any breaking changes immediately.
Alternative,
If the requirements process is onerous, then you should consider making sure
that none of the jobs you run are subject to constraints and entries for your
project do not appear in any of the files under the requirements team's purview
Please note that as we speak, a new team is being formed to take care of things.
So we'll do better with quicker reviews and reverts if needed. We'll also try to
figure out ways and means not to break projects inadvertently.
Thanks,
Dims
--
Davanum Srinivas :: https://twitter.com/dims
More information about the OpenStack-dev
mailing list