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
This commit is contained in:
parent
ebb3c3f732
commit
72093e26a5
@ -6,5 +6,14 @@ repository for it's specification reviews. Detailed information can be found
|
||||
`here <https://wiki.openstack.org/wiki/Blueprints#Neutron>`_. 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 <release>-backlog directory during the RC window and move all specs which didn't make the <release> 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.
|
||||
|
Loading…
Reference in New Issue
Block a user