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.
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
- Make sure the code compiles and all tests pass.
- 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.
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.
Make sure the code adheres to our coding guidelines.
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.