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]
