Page History

...

1. Defects are recorded as GitHub issue for the associated Pekko module.
2. All changes to main and release branches must be made via pull requests.
3. All pull requests
   
   1. must be reviewed and approved by at least one committer who is not the developer(s)
   2. Pekko reviewers should try to involve other Pekko committers if the change is not trivial
   3. large changes should have GitHub issues created for discussion first
   4. should be targeted at the `main` branch
   5. a backport PR can be considered when the original PR is merged
      1. any PR that changes existing APIs or internal behaviours is unlikely to be backported
   6. merges should ideally be of `Squash and Merge` type but we occasionally want to preserve the commit history of the PR branch and in this case, `Rebase and Merge` is okPekko committers should merge their own PRs when they have enough support to do so
   7. when a PR has been reviewed but requires trivial changes to be mergable (such as resolving a merge conflict without otherwise changing the general properties of the PR), the author may apply those changes and then merge the PR themselves. Larger updates require a new review.
4. We enforce the minimum review requirements using GitHub protection rules (defined in our .asf.yaml file) but we encourage developers and reviewers to allow open discussion. At the moment, there are not many active contributors so there may not be a lot of discussion.
5. In the end of the day, it is possible to revert changes if someone misses the original discussion. These discussions should seek consensus and try to involve the developers and reviewers of the original changes.
6. Try to assign milestone markers to Issues and PRs so that we can keep track of the versions where they are merged or where we intend to merge them.

...