So I think the core problem here is that we have gotten a sudden influx of contributions from new people and while this is the last thing to complain about there is definitely a point to be made that a couple of us are being overloaded right now. To note there is also a good reason for this rush, i.e. its ideal to put these new changes into 1.1.0-M1 so that people have opportune time to test them before full release.
Hence I would propose a 72 hour merge window for new features (i.e. new Source/Flow/Sink operators as an example) at least until M0 is voted and released, or in other words PR's that add new features should sit for a few days before being merged so that at least we can look at it properly. This should also alleviate concerns that features are being pushed by an in group without getting properly looked at by the rest of the Pekko community. For now I would keep this as a general guideline rather than an official rule because I would like to see how this plays out and so such a rule may also only be temporary due to the current state of affairs. On Wed, Jan 24, 2024 at 6:36 AM PJ Fanning <fannin...@gmail.com> wrote: > 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 > > -- 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
