Page History

...

If you haven't setup Github repository, please refer to the general information page.

When Before merging a Pull Request, a Committer:

...

• 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

...

• 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 Each commit SHOULD address one thing, e.g.:
    • should not SHOULD NOT fix a bug fix commit and reformatting things at once.
    • renamingsRenamings / refactorings / clean ups that do not change semantics/do not add new features.
• SHOULD rebase the PR and re-run CI tests.
  • It is impractical to require always running CI tests on the latest codebase before merging, because new commits can be merged during the CI execution.
  • SHOULD check the commits merged into the codebase after the CI being triggered.
    • If there is any conflict, or any commit that touches the same components/files that the PR does, it is recommended to at least re-compile the project and re-run the relevant test cases before merging.
• MUST make sure the latest version of the PR passes the CI tests.
  • Success CI builds from personal Azure also counts. In that case, please link to the build.
  • It’s also acceptable if there is not a complete success build but each stage has succeeded at least once. In that case, please link to all relevant builds.
  • See also Best practice handling test failures.

When merging a Pull Request:

• MUST NOT use merge commits.
• SHOULD NOT use the GitHub UI to merge Pull Request.
• SHOULD add "This closes #PR_ID." to the message of the last commit of the PR.
  • When doing so please make sure to not overwrite existing commit messages!

After merging a Pull Request:

• SHOULD back port 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 Add a comment listing the commit hash for each branch respectively.
  • check Check the JIRA data
    title, components and type are accurate title is meaningful fixVersion covers all versions.
    •   for For release-X.Y branches, pick the next upcoming release version.
    •   for 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).

Best practice handling test failures:

• Try reproducing the problem, see if the test failure is deterministic.
  • Try run the test locally.
  • If the problem cannot be reproduced locally, try re-run the CI build.
    • Sometimes the test failures might be deterministic but only in the CI environment.
  • If the test failure is deterministic, it is likely related to the PR changes, and further debugging is needed.
• For non-deterministic test failures, search on JIRA see if it has been reported.
  • If there’s an existing ticket, report the new instance and link to the build.
  • If there isn’t an existing ticket, create one.
• For a test instability of very high frequency, that significantly blocks new PRs from merging.
  • Consider upgrading the ticket to Critical or Blocker priority, to receive more attention.
  • Try reaching out to committers with expertise in relevant components to look into the issue.
  • Raise a discussion on temporarily disabling the relevant test cases, in order not to block other PRs.
    • The JIRA ticket must be made a Blocker before disabling the test cases.
    • The test cases must be re-enabled before the JIRA ticket is closed / downgraded.