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
