In an ideal world, this would be a great move. But "ideal" is pretty subjective, and I’m not sure our current reality matches up. For this to actually work without frustrating everyone, I think we’d need: 1. True coverage: At least 3 or 4+ active devs per repo who actually know the codebase well enough to give a meaningful review. 2. Productive reviews: A culture where we don't block PRs over minor nitpicks or change requests that don't actually add value for the code or the end user.
Maybe Maven Core has the numbers to handle the first point, but I’m really not convinced we’re there yet on the #2. Sticking to these requirements right now feels like it'll just create more bottlenecks and frustrations. So I’m a -1 on this. Cheers Olivier On Fri, 15 May 2026 at 20:45, Elliotte Rusty Harold <[email protected]> wrote: > > I'vd noticed that on at least some (maybe all?) of our repos PRs can > be and are being merged without any approving code reviews. We have > enough active developers that this shouldn't be necessary. This feels > increasingly important given the active state sponsored supply chain > attacks on many open source projects. > > We could add something like this to .asf.yaml to guarantee code reviews: > > protected_branches: > main: > required_status_checks: > # strict means "Require branches to be up to date before merging". > strict: true > required_pull_request_reviews: > require_last_push_approval: true > required_approving_review_count: 1 > > Contrary to what has been asserted in the past, this is not a veto. It > does not require authors to get approval from all reviewers, or > prevent merging PRs where one or more reviewers have requested > changes. It simply requires one other person to approve the PR. That's > what we do anyway 90%+ of the time and should be a low enough bar to > clear for anything important. > > -- > Elliotte Rusty Harold > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
