On 8/22/25 3:14 PM, Dumitru Ceara wrote: > 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
Obviously, typo, sorry: s/cover later/cover letter/ > 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
