Versions Compared

Old Version 2

changes.mady.by.user Claude Warren

Saved on

compared with

New Version Current

changes.mady.by.user Arnout Engelen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: described 'rebase+merge' vs 'squash+merge' merge strategy

1 Communication

  1. The communication channel of record is dev@pekko.apahceapache.org which is archived at https://lists.apache.org/list.html?dev@pekko.apache.org
  2. Issues relating to security must not be discussed publicly. See the ASF Security Policy. Pekko PPMC members will discuss the topic using the private@pekko.apache.org mailing list.
  3. Significant changes should be discussed on the dev mailing list. Releases are also discussed on the dev mailing list. Release candidates must be voted on using the dev mailing listAll discussion concerning changes must occur on the dev@pekko.apache.org mailing list.  If it is not on the mailing list it did not happen.
  4. Apache Pekko follows the Apache voting rules:   https://www.apache.org/foundation/voting.html
  5. It is ok to start discussions by raising a GitHub Issue, Pull Request or Discussion. If you intend working a large Pull Request, it is best to discuss it by raising a related GitHub issue first or by emailing the dev mailing list. These GitHub issues/PRs/discussions are recorded to https://lists.apache.org/list.html?notifications@pekko.apache.org
    1. If there is disagreement about how to proceed, then it is best to start a discussion on the dev mailing list.
    2. A vote can be called by a Pekko committer if a consensus has not been formed.
  6. Usage queries should ideally go the users@pekko.apache.org mailing list https://lists.apache.org/list.html?users@pekko.apache.org
  7. All communications should adhere to the ASF Code of Conduct.

2 Development

  1. Defects are recorded in the git 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 for code changes (e.g. changes that modify the code execution)must be associated with an issue.
    1. must be reviewed and approved by at least two committers one committer who are is not the developer(s).  
    2. must be voted on in the development list using the code modifications process documented in the Apache voting process document
  4. Trivial documentation changes (e.g. spelling errors, javadoc errors) are changes that do not affect code execution. 
    1. Trivial documentation changes may be approved by one committer who may also be the editor.
    2. Trivial documentation changes do not require discussion in the mailing list.
    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 ok
    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.
  6. 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.
  7. Pekko allows both the 'rebase+merge' and 'squash+merge' merge strategies. For multi-commit merges, make sure to only use 'rebase+merge' when the commit history is clean, and does not contain bad intermediate states. If you prefer your PR to be merged as 'rebase+merge', it is advisable to point this out in the initial PR message.
  8. 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.
  9. 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 themSubstantive documentation changes (e.g. not trivial)
  10. must be associated with an issue
  11. must be reviewed and approved by at least two committers who are not the editor(s).
    12. must be voted on in the development list using the code modifications process documented in the Apache voting process document.

3 Process Changes

  1. All processes are recorded in this wiki.
  2. In time, we hope to formalise a Pekko Improvement Proposals procedure. This procedure would be similar to similar procedures used in other large projects. Scala Improvement Process and Kafka Improvement Proposals are examples. In the interim, using GitHub Discussions and the dev mailing list are good ways to make proposals for new features and behaviour changes.
  3. Processes may be changed by the process specified in the Apache voting process document section on  procedural issues.