On 8/7/25 3:10 PM, Ilya Maximets wrote:
> On 8/4/25 8:20 PM, Mark Michelson via dev wrote:
>> For the past several releases of OVN, we have had to make adjustments
>> either to the soft freeze date or the soft freeze period in order to
>> accommodate the volume of new feature patches that are proposed.
>>
>> This series proposes two new policies that are designed to aid OVN
>> developers in being able to review patches in a less frantic way.
>>
>> Mark Michelson (2):
>> release-process: Add time between soft freeze and branching.
>> release-process: Change policy for feature review during soft freeze.
>>
>> Documentation/internals/release-process.rst | 16 ++++++++--------
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
Hi Mark, Ilya,
Indeed, thanks for putting this together!
>
> Thanks, Mark. As per previous discussions, I assume the intention is
> to get only one of these changes and not both. With that, I believe,
> both policy changes are aiming to do practically the same thing, which
> is to make people post their patches earlier, so they can be reviewed
> in time for branching. It's that approaches are a bit different, the
> first is to block extra two weeks, the second is to gate the freeze
> based on review status.
>
> IMO, since the real problem is getting reviews done, it's better if the
> policy is actually tied to the reviews instead of purely based on time.
> A few points here:
>
> - This will incentivize people to do more reviews upstream, e.g. if they
> were doing reviews behind closed doors before (the current version
> of the patch is missing the word "publicly").
>
> - It is more flexible, e.g. if someone posts a very simple feature a day
> before the freeze, it can be accepted if one day is actually enough
> to get a review. If we time-block the extra two weeks from posting
> anything new, then it prevents such simple features to be accepted,
> if someone thought of them during these two weeks.
>
> - As mentioned in the patches, blocking two extra weeks makes OVN not
> aligned with OVS branching, so can introduce extra synchronization
> problems when an OVN feature requires a new feature in OVS libraries
> that may not be accepted yet.
Ilya, I'm not sure I understand this specific point you're raising here.
Patch 1/2 moves OVN branching date 2 weeks later (extends soft freeze
by two weeks). Looking at the new dates, for the first release of 2026:
With the new OVN dates:
OVS soft freeze: Jan 1st (although I assume this will
actually be Friday, Jan 2nd)
OVS release branch creation: Jan 15th
OVN soft freeze: Jan 23rd
OVS release: Feb 15th
OVN release branch creation: Feb 20th
OVN release: Mar 20th
And with the old OVN dates:
OVS soft freeze: Jan 1st (although I assume this will
actually be Friday, Jan 2nd)
OVS release branch creation: Jan 15th
OVN soft freeze: Jan 15th
OVN release branch creation: Feb 1st (OVN release branch creation
happens before OVS release)
OVS release: Feb 15th
OVN release: Mar 1st
So it seems to me that the extended OVN soft freeze actually makes
things simpler because when the OVN release branch is created the OVS
submodule in OVN will likely point to an already released OVS version.
That wasn't the case with the old schedule.
>
> - Reviews more accurately represent the pace of development. Even with
> extended freeze duration, there is no guarantee that all what was
> posted will get accepted. There is no such guarantee with the review
> requirement as well, but if something was already reviewed at least
> once it means that someone is already familiar with the code and it
> would be much faster for them to do the next round. And it also shows
> that there is some real interest from multiple people to get the
> change in. So there is a higher chance that OVN community actually
> has capacity to handle all the eligible changes during the freeze
> without any heroic efforts.
>
> - Bonus: Less confusion between OVS and OVN policies, as OVS requires
> patches to be publicly discussed and reviewed before the soft freeze
> starts.
>
Personally, I wasn't a big fan of this OVS policy as it sounds to me
like in theory (and I want to stress here that I _haven't_ seen this
happen in the OVS community in practice) it could provide "usual"
reviewers with a "tool" to block specific contributions from being
accepted. That's because an _intentional_ lack of reviews from the
community reviewers would automatically disqualify the contribution from
being accepted in the next release.
> Of course, all that can be worked around and exceptions can be made, but
> if we're defining the policy, then we should define one that is the most
> suitable for different situations, exceptions should stay exceptional.
>
> All in all, this seems like quantity vs quality trade off. And I believe
> the "quality" is the better one in this particular case.
>
That's a fair point and, as Mark pointed out in the beginning of the
cover later, the current OVN policy didn't work either and we had to
delay soft freeze for a couple of release cycles already. We might as
well try something else.
For now, I think I'm in favor with both changes this RFC is proposing.
Regards,
Dumitru
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
