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(-) >
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. - 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. 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. My 2c. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
