add verbage about branches
improve CB-xxxx bits and punctuation
|Deletions are marked like this.||Additions are marked like this.|
|Line 14:||Line 14:|
|* For trivial changes, this is not necessary.||* For trivial changes, this is not necessary|
|Line 30:||Line 30:|
|* Re-write commit messages to include JIRA issue numbers in the form [CB-####]|| * Note that `git am` will strip `[CB-####]`, so if the message is in that syntax, you will have to restore it.
* Re-write commit messages to include JIRA issue numbers in the form CB-####.
|Line 71:||Line 72:|
|* The "Fix Version" field is used for the purpose of Release Notes, and should be set to the [[VersioningAndReleaseStrategy|CadVer]]||* The "Fix Version" field is used for the purpose of Release Notes, and should be set to the [[VersioningAndReleaseStrategy|CadVer]].|
Processing Pull Requests
Ensure you are familiar with CommitterWorkflow.
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
- For trivial changes, this is not necessary
Find their name on: https://people.apache.org/committer-index.html#unlistedclas
If it is not there, direct them to http://www.apache.org/licenses/#clas
Step 3: Merge the change
Run the following as an exemplary way to merge to master:
# 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.
Note that git am will strip [CB-####], so if the message is in that syntax, you will have to restore it.
- Re-write commit messages to include JIRA issue numbers in the form CB-####.
Be aware that not all repos use "master" as the active development branch. See "Which Branch to Commit To" in Committer Workflow.
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
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 you just performed and ask them to close the pull request. The instructions for closing a pull request are in the Contributor Workflow in the section titled "When Your Pull Request is Accepted".