So we have divided opinions about changing the number of reviewers. Can we park that part of the discussion and talk about keeping PRs open for some minimum period of time?
I proposed 72 hours and ok with something like 48 but would be against going as low as 24. I'm seeing cases where PRs are coming in and merged within a few hours giving people who need a few hours sleep no time to review. I would argue strongly that if we want a 1.1.0-M0 release soon, then we will need to start being more careful about what gets merged. I think we need some compromises here. I think it is unhealthy to be threatening -1s to stifle debate. On Tue 23 Jan 2024, 17:03 kerr, <hepin1...@gmail.com> wrote: > I will always -1 before 1.1.0, so slow. and we are in different time zones > too, too small group. > If we have 10+ active commuters / reviewers, this is good, but for now, -1. > > 何品 > > > laglangyue <laglan...@foxmail.com> 于2024年1月23日周二 23:16写道： > > > vote +1 for double approval， > > > > > > Almost all the TLP projects I have participated in are like this > > > > 发自我的iPhone > > > > > > ------------------ Original ------------------ > > From: Claude Warren, Jr <claude.war...@aiven.io.INVALID> > > Date: Tue,Jan 23,2024 10:21 PM > > To: dev <dev@pekko.apache.org> > > Subject: Re: [DISCUSS] is it time to change the Pekko Processes? > > > > > > > > +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 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 > > > <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 > > > >
