From 72093e26a5a61c78e046d994f114ae650efdf482 Mon Sep 17 00:00:00 2001 From: Kyle Mestery Date: Thu, 26 Mar 2015 12:58:08 +0000 Subject: [PATCH] Add language around re-proposing specs for new releases Attempt to provide guidance over how we handle specs which do not make a release and want to be re-proposed into the next release. Change-Id: I3820438e81fced0630c471f1e240174e63bbf062 --- doc/source/policies/blueprints.rst | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/doc/source/policies/blueprints.rst b/doc/source/policies/blueprints.rst index 3de007803..50ab9e766 100644 --- a/doc/source/policies/blueprints.rst +++ b/doc/source/policies/blueprints.rst @@ -6,5 +6,14 @@ repository for it's specification reviews. Detailed information can be found `here `_. Please also find additional information in the reviews.rst file. -Please note that at the start of each cycle, any BP/spec which did not make it in the release -will need to be resubmitted and approved for the next cycle. +Neutron BP and Spec Notes +------------------------- + +There are occasions when a spec will be approved and the code will not land in the cycle it was targeted at. For these cases, +the workflow to get the spec into the next release is as follows: + +* The PTL will create a -backlog directory during the RC window and move all specs which didn't make the there. +* Anyone can propose a patch to neutron-specs which moves a spec from the previous release into the new release directory. + +The specs which are moved in this way can be fast-tracked into the next release. Please note that it is required to re-propose +the spec for the new release however. -- 2.45.2