On 8/27/25 12:03 PM, Ilya Maximets 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. > > Ah, sorry, I misread the dates in the first patch. Indeed this point is > not a concern then. > >> >> 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. > > "intentional lack of reviews from the community" is a strange thing to say. > In any case it would mean that "community doesn't want the change" and so > the project likely shouldn't accept it anyway. >
Sure, but in my opinion the community should nack/reject/whatever the change explicitly. In any case, it's a minor concern on my side, like I said above, I don't really think anything like this happens in practice in the OVS/OVN communities. It was more of a "theoretical worry" I had when interpreting the OVS policy ad litteram. >> >>> 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. > > I'm a little concerned that 2 months is a little too long from the freeze > to release, but we can try, I guess. So, 2 or 1+2 from my side, if others > think that having both changes is better. > > Best regards, Ilya Maximets. > Regards, Dumitru _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
