> 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 understand your starting point of wanting perfection, and I also understand the demands of different people in the community. Everyone’s time zone is different. If everyone is online, it is best to collaborate quickly. Some things are not that complicated. If later classmates find that it is not good, Then of course it can be further optimized. If the Eiffel ironwork is rusty, what about the code? After all, we are not working together, in the same company, doing this full-time. I suggest a simplified process. When submitting a PR, you should give priority to commenting on it yourself. As the first author and first reviewer, if you feel that you are satisfied with it, you can switch from draft status to reviewable. Anyone else who sees this can LGTM. If there are very simple changes, don't comment and just start making changes. Some types of copywriting can be expressed authentically by students who are native English speakers. On the contrary, it is easy for me to make mistakes. At this time, you can use your own advantages and make changes directly. . Matthew is better at using github than I am. Once you change it to your satisfaction, it's basically the same thing. Can be merged directly. I don’t recommend using various blocks, as this will block the process. Of course, I don’t recommend merging codes easily. Any merged code must be done to your own satisfaction and to be as responsible as possible. We don’t want low-quality code, but we want fast collaboration. We are all relatively experienced developers and users. I think the possibility of code corruption is relatively small. At the same time, as an open source project, everyone is actually a reviewer. The Spring Festival is coming soon, and just like your Christmas, we may spend less time online and spend more time with our families, because the current reviewers are relatively small, and such rules can easily bring the project to a standstill. This is my little suggestion, thank you. 何品 PJ Fanning <fannin...@apache.org> 于2024年1月24日周三 01:30写道： > 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 > > > > > > >
