The current documentation says that new features that have been posted
for review before the soft freeze date may be considered for inclusion
in the upcoming release. The issue with this policy is that when the
soft freeze date hits, many new feature reviews get posted on the same
day. This results in an unforeseen load of reviews to complete during
the soft freeze period.
This change makes it so that only features that have received review
feedback prior to the soft freeze date are considered for inclusion in
the upcoming version. This makes it less likely for patches to show up
spontaneously at the last minute, and any that do will not be considered
for inclusion. This hopefully makes soft freeze easier to deal with and
encourages features to be developed and reviewed in a timely manner.
Signed-off-by: Mark Michelson <mmich...@redhat.com>
---
Documentation/internals/release-process.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/internals/release-process.rst
b/Documentation/internals/release-process.rst
index 747fca34b..d5b9275c3 100644
--- a/Documentation/internals/release-process.rst
+++ b/Documentation/internals/release-process.rst
@@ -46,8 +46,8 @@ Scheduling`_ for the timing of each stage:
During the freeze, we ask committers to refrain from applying patches that
add new features unless those patches were already posted for public review
- before the freeze began. Bug fixes are welcome at any time. Please propose
- and discuss exceptions on ovs-dev.
+ and had received review feedback before the freeze began. Bug fixes are
+ welcome at any time. Please propose and discuss exceptions on ovs-dev.
2. Fork a release branch from main, named for the expected release number,
e.g. "branch-25.09" for the branch that will yield OVN 25.09.x.
--
2.49.0
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
