On Fri, Aug 22, 2025 at 3:16 PM Dumitru Ceara via dev < ovs-dev@openvswitch.org> wrote:
> 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 > > Thank you Mark, Ilya and Dumitru, for the discussion and the proposal. Both of those changes make sense to me, I have just one small comment on 2/2. Regards, Ales _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
