| Message ID | 20250804182104.390669-3-mmichels@redhat.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Release Policy Updates | expand |
| Context | Check | Description |
|---|---|---|
| ovsrobot/apply-robot | success | apply and check: success |
| ovsrobot/github-robot-_Build_and_Test | success | github build: passed |
| ovsrobot/github-robot-_ovn-kubernetes | success | github build: passed |
On Mon, Aug 4, 2025 at 8:21 PM Mark Michelson via dev < ovs-dev@openvswitch.org> wrote: > 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 <mmichels@redhat.com> > --- > Hi Mark, I have one small comment down below. > 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 > I think we should be explicit that only feedback shared on ML is valid. In other words pre-acked patch shouldn't count. + 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 > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > Thanks, Ales
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.
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 <mmichels@redhat.com> --- Documentation/internals/release-process.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)