Hi all, (I moved OVN maintainers in "to", the rest in "cc")
Based on the feedback in this thread I went ahead and enabled branch protection for old OVN branches: branch-20.*, branch-21.*, branch-22.*, branch-23.*, branch-24.*. These branches are now locked as "read-only". I didn't enable protection for branches 25.03 and 25.09 yet as we do occasionally backport fixes to those too even though they're not officially supported anymore (one example request of my own [0]). But we should lock those too in the near future I guess. Regards, Dumitru [0] https://mail.openvswitch.org/pipermail/ovs-dev/2026-July/434589.html On 7/29/26 9:40 AM, Ales Musil wrote: > On Tue, Jul 28, 2026 at 5:01 PM Numan Siddique <[email protected]> wrote: > >> >> >> >> On Tue, Jul 28, 2026, 5:02 a.m. Dumitru Ceara <[email protected]> wrote: >> >>> Hi all, >>> >>> On 7/24/26 10:52 AM, Eelco Chaudron wrote: >>>> >>>> >>>> On 23 Jul 2026, at 23:16, Ilya Maximets wrote: >>>> >>>>> On 7/23/26 10:56 PM, Numan Siddique wrote: >>>>>> On Thu, Jul 23, 2026 at 4:51 PM Ilya Maximets <[email protected]> >>> wrote: >>>>>>> >>>>>>> On 7/23/26 10:08 PM, Numan Siddique wrote: >>>>>>>> On Thu, Jul 23, 2026 at 3:59 PM Ilya Maximets <[email protected]> >>> wrote: >>>>>>>>> >>>>>>>>> On 7/23/26 9:52 PM, Numan Siddique wrote: >>>>>>>>>> Hi OVN and OVS maintainers >>>>>>>>>> >>>>>>>>>> Jimmy (CC'ed) has raised this PR issue for OVN - >>>>>>>>>> https://github.com/ovn-org/ovn/issues/317 >>>>>>>>>> about protecting the release branches. >>>>>>>>>> >>>>>>>>>> Are there any reservations against this request ? Or any >>> downsides ? >>>>>>>>>> >>>>>>>>>> We are setting up pull mirror rules for our downstream OVS and OVN >>>>>>>>>> repos and we want to base it on the protected branches. >>>>>>>>>> >>>>>>>>>> Looks like OVS branches were protected until branch-3.2. >>>>>>>>>> >>>>>>>>>> Can we branch protections for both OVS and OVN ? >>>>>>>>> >>>>>>>>> Branch protection is a mechanism to prevent direct pushes, AFAIR. >>>>>>>>> So, the only way to merge changes becomes a github PR. Which is >>>>>>>>> not how our development process works. We rely on maintainers >>>>>>>>> pushing code directly to branches where it belongs. And we trust >>>>>>>>> our maintainers to be careful with that. >>>>>>>>> >>>>>>>> >>>>>>>> Thanks Ilya for the reply. >>>>>>>> >>>>>>>> I think it is possible to have direct pushes from the maintainers >>> even >>>>>>>> if the branch is protected >>>>>>>> by adding rules to allow maintainers. But it won't be possible for >>>>>>>> the force pushes. >>>>>>>> >>>>>>>> Let me know if it makes sense to protect the branches and also >>> allow maintainers >>>>>>>> to push. >>>>>>> >>>>>>> Maintainers are the only ones with the write access, i.e., the only >>>>>>> ones who can push. Is there a point in protection rules if everyone >>>>>>> who can push will still be able to do so? >>>>>>> >>>>>>> We do also allow maintainers to use force-push for quickly fixing >>>>>>> their mistakes. And mistakes are a part of having write access. >>>>>>> Obviously, it's not something that should be used lightly or in any >>>>>>> way frequently. But it's good to have a tool when it is necessary. >>>>>> >>>>>> Got it. I agree there and I myself have done a few mistakes before. >>>>>> >>>>>>> >>>>>>> I'm also not sure what is the original idea behind only mirroring >>>>>>> protected branches? Could you elaborate? >>>>>>> >>>>>> >>>>>> From what I understand, security wants to only mirror the upstream >>>>>> code from the branches which are protected. >>>>> >>>>> Fun fact: I just checked and it is possible to create a branch >>> protection >>>>> rule with the following configuration: >>>>> >>>>> 1. Allow force pushes (for everyone with push access) >>>>> 2. Allow branch deletions (for everyone with push access) >>>>> 3. Require linear history. >>>>> >>>>> This rule adds no real restrictions that are meaningful to our >>> development >>>>> process. The only restriction is a linear history that we use anyway. >>>>> >>>>> But, after applying it to a branch, it now shows a shield icon with the >>>>> 'This branch is protected with branch protections' legend. And since >>> it >>>>> is a legacy branch protection rule, nobody except for the owner can see >>>>> what this protection rule actually is. >>>>> >>>>> Similar thing can be done with the branch 'ruleset', but people can see >>>>> what the ruleset is enforcing byt clicking on it. >>>>> >>>>> Though rulesets allow creation of a fully restrictive rule and make it >>>>> bypassed by everyone with the Write role. Bypasses are not reported in >>>>> the UI, so there will be a rule, but it will never be enforced in >>> practice, >>>>> while being reported as 'Active - This ruleset will be enforced'. >>>>> >>>>> All in all, unless you're the organization owner, the branch protection >>>>> status on the branches page means absolutely nothing. >>>> >>>> Adding protection without restricting maintainers is just putting a >>> "Protected" sticker on the branch, looks good, does nothing. As Ilya found, >>> we would basically just get a free badge. Also, it makes no sense to change >>> our development process just for this. >>>> >>> >>> I agree, our current process (for both OVS and OVN) requires pushing to >>> supported branches. I don't think we should change anything about the >>> currently supported branches. >>> >>> We could, for OVN, protect all the currently unsupported branches >>> though. I think that would mean everything < branch-24.03. >>> >>> I can do that if the other OVN maintainers agree. >>> >> >> +1 from me. >> >> Numan >> > > I'm fine with that too. > > Regards, > Ales > > >> >> >>>>>> >>>>>> Maybe @[email protected] can perhaps elaborate more as he >>>>>> is the one who created the ticket. >>>>>> >>>>>> Thanks >>>>>> Numan >>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Branch protection is enabled on OVS branches that are no longer >>>>>>>>> maintained to prevent accidental pushes. They are just frozen in >>>>>>>>> time. Same could be done for OVN. >>>>>>>> >>>>>>>> I see. This explains why older branches have protection. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Numan >>>>>>>> >>>>>>>> >>>>>>>> But we can't do that for >>>>>>>>> currently maintained branches. >>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, Ilya Maximets. >>>>>>> >>>> >>> >>> Regards, >>> Dumitru >>> >>> >> >> > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
