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 >>> > > > >>> > >>> >>
