Differences between revisions 1 and 2
Revision 1 as of 2013-08-30 14:41:22
Size: 3158
Editor: AndrewGrieve
Comment:
Revision 2 as of 2013-09-18 15:00:21
Size: 3168
Editor: AndrewGrieve
Comment:
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
git remote add foo git://github.com/TheirUserName/cordova-docs.git
git fetch foo
git cherry-pick 5d3e1b6 # For each commit ID in their branch.
# REPO_NAME example: "js"
# PULL_REQUEST_NUMBER example: "44"
curl https://github.com/apache/cordova-REPO_NAME/pull/PULL_REQUEST_NUMBER.patch | git am
Line 27: Line 27:
The last step will let you interactively review the changes being made to master. You should: The rebase step will let you interactively review the changes being made to master. You should:

Processing Pull Requests

Step 0:

Step 1: Review the change (part 1)

  • Ensure that we actually want the change (if unsure, bring it up on the ML)
  • If there is no JIRA issue for the change, create one
    • Ensure the JIRA issue has a link to the pull request
    • Ensure the pull request has a link to the JIRA issue
  • View the user's branch in github and request changes be made (if applicable) by adding comments in the web interface

Step 2: Ensure that they have signed the Contributor Agreement

Step 3: Merge the change

Run the following:

# REPO_NAME example: "js"
# PULL_REQUEST_NUMBER example: "44"
curl https://github.com/apache/cordova-REPO_NAME/pull/PULL_REQUEST_NUMBER.patch | git am
git rebase origin/master -i

The rebase step will let you interactively review the changes being made to master. You should:

  • Squash as many commits as is reasonable together.
  • Re-write commit messages to include JIRA issue numbers in the form [CB-####]

Step 4: Check the author

git keeps track of the author of commits separately from the committer of the commit.

Typically, both of these values are set to the person submitting the pull request. After your pull/merge/rebase/whatever work, you may find the values have changed - or not. What we would typically be looking for is the final commit to have YOU as the committer and the original author as the author.

You can check these fields with the following command:

git log --pretty=full

If the author is set to YOU, and you'd like to reset it to the original author, you can amend the commit:

git commit --amend --author=some_author_id_here

Step 5: Review the change (part 2)

  • You are responsible for testing the changes that push.
  • This includes:
    • All automated tests in mobile-spec
    • Manual tests in mobile-spec that might be affected by the change
    • Platform-specific unit tests (i.e., cordova-android/test, cordova-ios/CordovaLibTests, cordova-js: grunt test, cordova-plugman: npm test)

  • If there is no existing test that exercises your code, add one!
  • If you are writing documentation (i.e., cordova-docs), be aware of the style guidelines.

Step 6: Push the change

git push

Step 7: Update JIRA

  • An Apache bot should have already added a comment to the issue with your commit ID (based on the CB-1234 being in the commit message).
  • Close the issue, and set the "Fix Version" field.
    • The "Fix Version" field is used for the purpose of Release Notes, and should be set to the CadVer

Step 8: Final details

  • Respond to pull request on github with link to their commit and ask them to close the pull request.

ProcessingPullRequests (last edited 2014-03-13 03:03:05 by AndrewGrieve)