I have defered some to 2.0.x, and seems the pr queue is fine now. I will try to burn the queue at weekend, and there is some personal issue on @laglangyue, we can defer that operator to 1.0.0-M2 too. Hope both of us have a nice day, it's OSS, no need to burn us.
何品 Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> 于2024年1月24日周三 08:13写道： > 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 >
