You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

This page outlines guidelines for merging Pull Requests.


(warning) NOTE: Due to recently found synchronization issue between GitBox and Github repositories, committers should only use Github repositories for pushing commits.

If you haven't setup Github repository push. Please refer to the general information page.


When merging a Pull Request, a Committer:

  • MUST NOT use merge commits
  • SHOULD rebase the PR and re-run Travis before merging
    • If you have linked your Apache and GitHub accounts you can rebase the PR itself and/or restart the Travis build
    • If you have not linked your accounts create a rebased copy in your own repository and run Travis
  • MAY use the GitHub UI to merge Pull Requests IF it has a recent Travis build
    •   IF you're pushing manually you MAY amend the commit message with "This closes #PR_ID."
      • When doing so please make sure to not overwrite existing commit messages!
  • MUST make sure that all commits reference the appropriate JIRA
  • SHOULD make sure that all merged commits have a component tag attached to them
  • MUST ensure a clean commit history, where each commit is meaningful by itself
    • MUST squash fixup commits (for example commits that are addressing review comments)
    • each commit SHOULD address one thing, e.g.:
      • should not fix a bug fix commit and reformatting things at once
      • renamings/refactorings/clean ups that do not change semantics/do not add new features
  • SHOULD backport bug-fixes to the 2 last versions (e.g., once 1.7 is released, include them in master, release-1.7, release-1.6)
    • Changes that affect Flink's behavior (in a way that could break setups) SHOULD NOT be back-ported.
  • MUST close the JIRA
    • add a comment listing the commit hash for each branch respectively
    • check the JIRA data
      • title, components and type are accurate
      • title is meaningful
      • fixVersion covers all versions
        •   for release-X.Y branches, pick the next upcoming release version
        •   for master branch, include the next release version (e.g. 1.8.0), unless it was also merged for the first release in the previous series (1.7.0)
  • No labels