On 11.10.2024 22:59, Dumitru Ceara wrote:

Sorry for the confusion.  I was trying to suggest to bump the
submodule on all OVN stable branches to the current tip of a
stable OVS release branch.  That's what I think our documentation
suggests:

https://github.com/ovn-org/ovn/blob/main/Documentation/internals/ovs_submodule.rst#submodules-for-releases

Right now we have this:
24.09: c598c05c85b2 ("Set release date for 3.4.0.")
24.03: f19448b86189 ("github: Update python to 3.12.") - branch-3.3
23.09: c88a35fc29f0 ("github: Update python to 3.12.") - branch-3.2
23.03: 8fd5f77cd84e ("ovsdb-idl: Preserve change_seqno when deleting rows.") - 
branch-3.1
22.12: 8fd5f77cd84e ("ovsdb-idl: Preserve change_seqno when deleting rows.") - 
branch-3.1
22.09: 94191b7a4926 ("ovsdb-idl: Preserve change_seqno when deleting rows.") - 
branch-3.0
22.06: 94191b7a4926 ("ovsdb-idl: Preserve change_seqno when deleting rows.") - 
branch-3.0
22.03: 94191b7a4926 ("ovsdb-idl: Preserve change_seqno when deleting rows.") - 
branch-3.0

We could bump the submodule on all these branches to the tip of the
OVS branch they're already tracking and I think we should be fine.

OVS commit 335a5deac3ff ("ovs-atomic: Fix inclusion of Clang header by
GCC 14.") was backported to all branches down to branch-3.0.



If yes, I've got a question: shouldn't we bump to f59f19bf6 (ovsdb-idl:
Fix IDL memory leak.) instead?



If we do what I suggest above we'll also get this fix.

Our documentation also says:
"
For choice 1, the decision of whether to update the submodule commit to OVS 
branch-Z is based on several factors.
    Is OVN release X still being supported?
    Is there any known benefit to updating the submodule? E.g., are there 
performance improvements we could take advantage of by updating the submodule?
    Is there risk in updating the submodule?
"

While I understand it's riskier to bump to the tip of the stable OVS
branch (potentially across minor OVS versions) the alternative of
bumping strictly to the commit that fixes the compilation error also
carries some risks: we might be missing follow up fixes that went in
afterwards.

However, I didn't do a thorough review yet of what other commits we'd
be picking up on each branch.  I'll try to do that when the patches
are posted.

What do you think?

Thanks for the detailed description!

I've read through the ovs_submodule document and your suggestion is almost what 
I wanted to do. One note is that I'd propose to bump branch-3.4, branch-3.3, 
branch-3.2 and branch-3.1 -based OVN branches to commit "ofproto-dpif: Improve 
load balancing in dp_hash select groups." as it is the tip of these branches. 
And branch-3.0 -based OVN branches to bump to a9fb87867 "selinux: Update policy 
file." commit.

After all autotests pass, I can submit patches.

Do you see such approach reasonable?

--
Regards,
Vladislav Odintsov
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to