The releases are off-topic here but so far, I think we've been discussing a milestone release not a full release - i.e. 1.1.0-M1. If we make any non-trivial changes after that, then we would have a 1.1.0-M2. When we stop making non-trivial changes, we can then go for a 1.1.0-RC1 that could become 1.1.0.
So far, we have a daily stream of new changes. This is not something that says a 1.1.0 is imminent. I'm happy to press on a 1.1.0-M1 but I expect that we will continue to keep making non-trivial extra changes which will ultimately push out a 1.1.0 release to some point fairly far in the future. We can start a separate discussion about 1.1.0-M1 but right now, we need to end up with a quiet period where we don't have more and more PRs. On Tue, 23 Jan 2024 at 19:48, kerr <hepin1...@gmail.com> wrote: > > 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 > >>>> > > > > >>>> > > >>>> > >>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
