+1 on > * PRs should have 2 approvals Note the wording: "should" indicates a recommendation. I think the strong recommendation should be 2 approvals. This allows leeway for when there is an emergency or when there are not enough people to review the request. On the other hand the lack of people to review requests is indicative of needing more reviewers/committers. Chicken and egg really, but if you have so many pull requests that you can't keep up there is probably at least one committer candidate hiding in the pool of submitters.
On Mon, Jan 22, 2024 at 10:46 PM Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> wrote: > *collectors should be connectors > > On Tue, Jan 23, 2024 at 8:17 AM Matthew de Detrich < > matthew.dedetr...@aiven.io> wrote: > > > I will have a stronger think about this with a full reply, but this part > > specifically > > > > > * PRs should have 2 approvals > > > > Is a dead no from me, there are 2 main reasons why. The first is that we > > although the speed of PR's have increased, the amount of reviewers have > not > > and we will get into a situation where there are a lot of PR's sitting > > there for a long time. > > > > Secondly Pekko is a bit interesting in that it's not just a single > project > > but rather a > > collection of many projects and even if we do fix the amount of reviewers > > there are projects > > such as collectors or management or kafka where 2 reviewers is just too > > much. There may > > be an argument that Pekko core specifically should have 2 reviewers since > > its so core and > > critical (and this is the rule that Akka had) but I am not sure if ASF > > allows that amount of > > granularity in the review process. > > > > I also think the timing for this is not the best, while its true that we > > are getting more > > actual feature/bug contributions then before there is still going to be a > > lot of admin/build tool > > related changes where 2 reviewers is still too much. > > > > On Tue, Jan 23, 2024 at 4:49 AM PJ Fanning <fannin...@apache.org> wrote: > > > >> Hi everyone, > >> > >> The existing Processes [1] page was designed for a time when most of > >> our changes were related to rebranding as Pekko and getting builds > >> working - generally, getting a set of v1.0.0 releases done. > >> > >> Now that we are getting lots of Pekko 1.1 PRs, I think the Processes > >> don't allow us enough time for reviewing the changes. The community > >> has probably grown enough that we should be able to require more > >> reviews. > >> > >> I'm going to propose: > >> * PRs should have 2 approvals > >> * that PRs need to be open at least 72 hours before they are merged > >> * if the PR is from someone with commit privileges, then they should > >> merge their own PRs after the 72 hours if there are enough approvals. > >> * If the PR is not from someone with commit privileges, then anyone > >> with commit privileges can merge it after the 72 hours with enough > >> approvals > >> > >> What do people think? > >> > >> [1] https://cwiki.apache.org/confluence/display/PEKKO/Processes > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > >> For additional commands, e-mail: dev-h...@pekko.apache.org > >> > >> > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Alexanderufer 3-7, 10117 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > -- > > Matthew de Detrich > > *Aiven Deutschland GmbH* > > Immanuelkirchstraße 26, 10405 Berlin > > Alexanderufer 3-7, 10117 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > *m:* +491603708037 > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io >
