The question is really review then commit or the old style commit then review. Last years prove RTC has value due to auto motions, even for releases (some projects adoptée it more than t'en years ago).
While for releases I dont care much, for code acceptable not encouraging automerge without previous sibling review sounds better and saner for asf (security, community, quality, discussion wide). 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, 16:41, Slawomir Jaranowski <[email protected]> a écrit : > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
