I think we can do this after the 1.1.0 released and have accumulated enough active contributors, I recently invited some developers from China to join the contributions of pekko, some of them even have the background of OCaml, haskell, Elixir, I think that a good start.
And this should not be a hard rule too, simple change can be merged with 1 lgtm, eg: a typo. And any significant change, the origin user can mark it as draft, Both Akka , ZIO and FS2 ship things fast, especially ZIO, no document, just code, then got merged, we certainly will not go that way, but still will not need a hard rule. Anyway, I think this is kind of trust problem too. The world is changing so fast. In many cases, if you don’t keep up with the pace, you will fall behind. Even if Akka has full-time developers, what about our open source contributors? Furthermore, not everyone has time every day, and I’ve seen many PRs eventually stop. If only two people have time recently, and the others may not have the time or interest to do these things due to other life matters, how can this rule be carried out? You can naturally change the rules to LGTM for many people, but at least I won't have time any time soon. 1. I have to be busy with my work performance 2. My body needs to recover and I need surgery. 3. It’s Chinese New Year I think open source projects, especially projects that have not yet graduated, should cherish the high-quality developers around them and straighten out the tool chain instead of sticking to the rules. After all, everything has two sides, right? How many developers left Akka because Akka members could decide what to merge and what not to merge? Hope we can finally deliver the special value of Pekko, thank you. Finally, I would like to add that due to the existence of the firewall, it is very difficult for Chinese developer contributors to access, pull, push, comment . I hope everyone will be more understanding and friendly, and work together for a community with a shared future for mankind. 何品 PJ Fanning <fannin...@apache.org> 于2024年1月23日周二 02:11写道： > I forgot to include the fact that we need some exceptions to the 72 hour > rule. > > Can I suggest cases where there is some urgency? > * fixing a broken build > * fixing a security issue > * something that is generally holding up a release > > The PR author should include the fact they are requesting an expedited > merge in the PT description. > > Again, this is just a proposal for discussion and doesn't apply until > we have discussed these changes and possibly voted on them. > > > On Mon, 22 Jan 2024 at 18:49, PJ Fanning <fannin...@apache.org> 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > >
