Re: Code review requirements

Hi,

From me also -1

Agree with Tamás

and more:
 - release process and tool are not ready - if I'm misses about it,
please try do release first in new way without write to default
branch, next we can talk
 - I can create a fake account on on GitHub and switching between it -
one for create PR and one for approve
 - we have a vote process where artifact and commits are checked
before publishing
 - you can check reproducible build during vote
 - we have protected branches so force push with history override is disabled,
 - all commits are logged on public ML



On Fri, 15 May 2026 at 16:08, Tamás Cservenák <[email protected]> wrote:
>
> -1 to REQUIRE this
> +1 to ASK for this (on case-by-case basis)
>
> Our velocity is already affected by slow responses, just look at votes
> for example, and there have been PRs sitting since years.
>
> I find this more like a "let's shoot ourselves in our foot" thing,
> given past experience, to bring ourselves to a grinding halt.
>
> See here for example
> https://github.com/apache/maven-site/pull/321
>
> Thanks
> T
>
> On Fri, 15 May 2026 at 14:25, Romain Manni-Bucau <[email protected]> wrote:
> >
> > Makes a lot of sense to me, +1
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old
> > Blog <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
> > Javaccino founder (Java/.NET service - contact via linkedin)
> >
> > Le ven. 15 mai 2026, 12:47, Elliotte Rusty Harold <[email protected]> a
> > écrit :
> >
> > > 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]
>


-- 
Sławomir Jaranowski