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