Great write-up. Do you plan to capture it e.g. in project guide? > On 18 May 2016, at 13:43, Davanum Srinivas <dava...@gmail.com> wrote: > > 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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
