In any case, I always think this issue is a trust issue. I have never seen an application or system without bugs. Even now, I know that there are many undisclosed bugs/defects in the pekko/akka code base. If you don't ask questions or submit PRs, there won't be any problems, and everyone will live a more relaxed life. I believe in giving everyone professional qualities, and I also believe in everyone's attitude of starting from beginning to end. To use Ali's dialect, it is simple because of trust, and we must have the spirit of back-to-back. There are inherent difficulties in remote unpaid OSS collaboration. I hope everyone will work harder to overcome it. As for the code quality and feeling that are not good, anyone can find it. Submit a PR to fix it. Let us Let’s welcome 1.1.0 together. As for the feature set: I think it's almost done. I want to wait for the Chinese community's forall and exists operations to be merged, and PJ Fanning's ForkJoinPool JDK9 support. I think the rest can be left to 2.1. After all, the next version is 2.0, right? We can not provide any new features in version 2.0, only delete obsolete code, and require 2 LGTM.
If we plan to complete the release of 1.1.0-M1 this month, I recommend that we close our feature merge window this month. Subsequent branches for 1.1.0 will be all fixes. Then create a 2.0 branch. I don’t know what you think. Well, rules are dead, but people are alive. If the mountains don’t turn, the water will turn. If the water doesn’t turn, the boat will turn. Good night. 何品 kerr <hepin1...@gmail.com> 于2024年1月24日周三 02:31写道： > By the way, to use an Ali dialect, be the terminator of problems, don’t be > the one who raises them. The problem ends with me. > > 何品 > > > kerr <hepin1...@gmail.com> 于2024年1月24日周三 02:26写道： > >> At the same time, I suggest that we use a tick tock approach to release, >> with one version adding features, and one version polishing and deleting >> obsolete code. In this way we can let go, but also maintain a rhythm and a >> unified pace. >> 何品 >> >> >> kerr <hepin1...@gmail.com> 于2024年1月24日周三 02:22写道： >> >>> > 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 >>>> > > > >>>> > >>>> >>>
