From 4f17bc10ba0892b21cff6e88c8b2b52a81ee84a2 Mon Sep 17 00:00:00 2001 From: Nate Johnston Date: Thu, 2 Jul 2020 17:15:48 -0400 Subject: [PATCH] Change policy on neutron-lib migration Per the results of discussion at the Virtual PTG in June 2020, we are changing our policy with regards to neutron-lib code forklifts. We are signaling that the mass migration of code from neutron to neutron-lib will no longer be actively pursued, and simplifying the process for such migrations - should they become necessary - by using debtcollector removals. Change-Id: I5669caf7e579c066acc52887a7f31ee8e238093f --- doc/source/contributor/contributing.rst | 51 +++++-------------------- 1 file changed, 9 insertions(+), 42 deletions(-) diff --git a/doc/source/contributor/contributing.rst b/doc/source/contributor/contributing.rst index 3f8bc1b38..9ccd26a0f 100644 --- a/doc/source/contributor/contributing.rst +++ b/doc/source/contributor/contributing.rst @@ -15,6 +15,9 @@ The checklist below aims to provide guidance for developers rehoming (moving) co neutron-lib. Rehoming approaches that fall outside the scope herein will need to be considered on a case by case basis. +Please note that the effort to rehome existing code from neutron to neutron-lib +so that no stadium projects would import directly from neutron has been suspended. + The rehoming workflow procedure has four main phases: #. `Phase 1: Rehome`_ the code from neutron into neutron-lib. @@ -113,45 +116,9 @@ When the bot-proposed requirement patches have merged, your rehomed code can be Phase 4: Consume ~~~~~~~~~~~~~~~~ -It's critical that before you submit your patch to remove the rehomed code from its source that -you perform a diff between it and the rehomed version in neutron-lib to ensure nothing has -changed in the source. If something has changed in the source, you need to push and shepherd a -patch to neutron-lib with the difference(s) before proceeding with this consumption phase. - -The following guidelines are intended to provide a smooth transition to the rehomed code -in neutron-lib and minimize impacts to subprojects consuming the rehomed code from its -source. - -- If the change to consume the code from neutron-lib is widespread and/or "important", - introduce your intentions for the change via the Neutron team - `meeting slot `_ - for neutron-lib. Subsequently follow-up with an email to openstack-discuss list using a - subject with ``[neutron] neutron-lib impact`` providing additional details as necessary. - Ideally we can identify the main impacted subprojects by - `grepping the OpenStack code `_. -- Prepare a neutron core patch to remove and update the rehomed code from its source. - This can be done without a `debtcollector `_ - notice by following the steps here. In the patch's commit message include the ``NeutronLibImpact`` - so that we can easily `query `_ - for such changes. Mark the patch as a work in progress with a -1 workflow vote. -- If the change is significant enough, it may warrant a "reference implementation" in an - impacted subproject to ensure the impacts are fully understood. Testing this - change can be done using the ``Depends-On:`` approach described in the - `review guidelines <./review-guidelines.html>`_. -- If you are a core reviewer and about to approve a NeutronLibImpact change, please consider - checking the state of all Stadium subprojects by looking at the - `grafana periodic dashboard `_. - This dashboard shows the status of subprojects' unit tests against neutron and neutron-lib - master branches, and even though it is not exactly validating unit tests against a released - version of neutron-lib it may be enough of an alarm bell to indicate that something might - be wrong because of a patch that recently landed in neutron (assuming that the subprojects - still has direct neutron imports). The check happens daily therefore consider waiting to - approve if you are either aware of another impactful change recently merged that has not - been yet processed or you see failure rates spiking. -- All projects that have `neutron-lib-current `_ - should also be updated as part of consumption. - -Examples: - -- `348472 `_ removes a validator in neutron that - was rehomed to neutron-lib. +When code is rehomed from neutron-lib then the original location of the code +should be flagged with a `debtcollector removal +`_. +This will indicate to any consuming projects that the given code is deprecated. +Be sure that this change is accompanied by a release note that notes the +deprecation.