Page tree
Skip to end of metadata
Go to start of metadata

The ASF INFRA team maintains a mirror of our git repository over on GitHub. The changes on GitHub gets synced with the changes on GitBox, and vice versa for the changes on GitBox.

Normally, users can file their PRs on the GitHub repository using the GitHub web UI, and merging the PRs through the GitHub web UI will automatically reflect the changes on both the GitHub and the GitBox repositories.

Add the ASF GitBox git repository (optional)

See this guide.

Merge changes

The next step is to merge all changes on the Pull Request as a single commit. Through the GitHub web UI, users can select the option 'Squash and merge` (see screenshots below) upon merging. Please make sure that the pile of commits are squashed with the option, and that commit messages provide meaningful information provided by the author of each of the PRs. In our example below, `[PR-1] Add appropriate whitespace to README (#1)` will show up as the commit message. 

Check the commit message

See this guide for what to look for.

Check the pull request

  1. Make sure the code compiles and all tests pass.
    1. If the pull request changes any POM.xml file: Please either clean your local maven repository before testing OR wait for the build servers to confirm that the project builds. This is to avoid situations in which an artifact was renamed or removed but is still in your local maven repository.
    2. Test java code

    3. Test .Net code

  2. If the code touches code that you suspect might break on YARN or Mesos, please test on those environments. If you don't have access to a test environment, ask on the mailing list for help.

  3. Make sure the code adheres to our coding guidelines.

  4. Make sure that the additions don't create errors in a Apache RAT check via mvn apache-rat:check

Resolving issue vs Closing issue

The last step of merging a pull request is resolving the associated issue. Committer should resolve it, provide the current release number (the latest unreleased version) in "Fix version" field and provide a link to the pull request in the comment.

Issue should be closed only if no productive steps were taken for it, i.e. it is "won't fix" or "duplicate" or "contained by". If some work was done but it doesn't have pull request associated with it, the issue should be resolved by the person who did the work.


  • No labels