Hi Dumitru, On 15.10.2024 18:34, Dumitru Ceara wrote: > On 10/14/24 16:41, Vladislav Odintsov wrote: >> On 14.10.2024 16:13, Dumitru Ceara wrote: >>> On 10/14/24 15:01, Vladislav Odintsov wrote: >>>> On 14.10.2024 14:47, Dumitru Ceara wrote: >>>>> On 10/13/24 10:19, Vladislav Odintsov wrote: >>>>>> This picks up the following relevant OVS changes: >>>>>> a15ce086d ofproto-dpif: Improve load balancing in dp_hash select >>>>>> groups. >>>>>> 76ba41b5c vconn: Always properly free flow stats reply. >>>>>> 64cb90507 ovsdb-idl: Fix IDL memory leak. >>>>>> ... and others. >>>>>> >>>>>> Reported-at: >>>>>> https://mail.openvswitch.org/pipermail/ovs-dev/2024-October/417627.html >>>>>> Signed-off-by: Vladislav Odintsov <[email protected]> >>>>>> --- >>>>> Hi Vladislav, >>>>> >>>>>> ovs | 2 +- >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/ovs b/ovs >>>>>> index c598c05c8..a15ce086d 160000 >>>>>> --- a/ovs >>>>>> +++ b/ovs >>>>>> @@ -1 +1 @@ >>>>>> -Subproject commit c598c05c85b2d38874a0ce8f7f088f6aae4fdabc >>>>>> +Subproject commit a15ce086d41f9dfe6c1589333413b8e777401ef0 >>>>> This would make branch-24.09 use a newer submodule version than the OVN >>>>> main branch does. >>>>> >>>>> I think we need this commit on main too, what do you think? >>>> Hi Dumitru, >>>> >>>> Agree. >>>> >>>> The patch: >>>> https://patchwork.ozlabs.org/project/ovn/patch/[email protected]/ >>>> >>> I was talking offline to Ilya about all these bumps and he made a good >>> point: while the tip of OVS branch-3.y and the latest v3.y.z get almost >>> the same amount of testing in the OVS repo it might be a bit better to >>> use v3.y.z instead. That's because likely external users of OVS run >>> tagged OVS releases in production so those might get more external testing. >>> >>> I had a quick look at the main differences between choosing the tip of >>> branch-3.y and v3.y.z on all branches and I think we'd only miss: >>> >>> 99e7cf9cce1c vconn: Always properly free flow stats reply. >>> f59f19bf69a4 ovsdb-idl: Fix IDL memory leak. >>> >>> which might be OK. >>> >>> If you agree I can change your patches on all branches (no need to post >>> new ones) and apply them. >>> >>> What do you think? >> Well, I'm totally fine with this. Please feel free to modify my patches. >> > I prepared them here, it would be great if you could double check: > > https://github.com/dceara/ovn/tree/refs/heads/tmp-branch-24.03 > https://github.com/dceara/ovn/tree/refs/heads/tmp-branch-23.09 > https://github.com/dceara/ovn/tree/refs/heads/tmp-branch-23.03 > https://github.com/dceara/ovn/tree/refs/heads/tmp-branch-22.12 > https://github.com/dceara/ovn/tree/refs/heads/tmp-branch-22.09
Could you please update commit subject to "ovs: Bump submodule to OVS 3.0.7." for patches within branches branch-22.09, branch-22.06, branch-22.03? > https://github.com/dceara/ovn/tree/refs/heads/tmp-branch-22.06 > https://github.com/dceara/ovn/tree/refs/heads/tmp-branch-22.03 > > I skipped main and branch-24.09 because those are already on the latest > OVS v3.4.z. Thanks for the update, other than commit subject, these patches look good to me! > > >> Also, shouldn't we update documentation to reflect this approach in >> Documentation/internals/ovs_submodule.rst for further bumps? And if > We should, you're right, I'll prepare a patch. > >> talking about documentation, I've got one note, which should be covered >> by new process. Imagine situation, where quite old OVS branch (let's >> say, 3.0) has a wanted commit (for example, fix for build with new >> compiler or latest libs), but the new patch release is not created >> because it is not a critical problem). I'd say we either need to request >> OVS community to bump patch release or bump from release to commit sha. >> What do you think here? Or, just leave it as is and decide how to bump >> in flexible manner in each individual case? >> > I think this is not the common case so maybe we can leave it flexible > for now. > > Regards, > Dumitru > -- Regards, Vladislav Odintsov _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
