Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cordova Wiki" for change notification.
The "CommitterWorkflow" page has been changed by MarcelKinard: https://wiki.apache.org/cordova/CommitterWorkflow?action=diff&rev1=20&rev2=21 Comment: added verbage about test expectations * For small changes, private topic branches are preferred. * Note: You should never rebase a public topic branch! + == Step 4: Make your changes == + * Thank you for making the world a better place. + + == Step 5: Test your changes == + * The author is responsible to test their own changes and correct any problems with their changes before a pull request is submitted (contributor authored) or it lands in the stream (committer authored). The testing includes both verifying the function they added/touched, plus running the test suites to verify there are no regressions. + * When we say "run the test suites" this includes all automated tests in mobile-spec, manual tests in mobile-spec that might be affected by the change, and any platform-specific unit tests (i.e., cordova-android/test, cordova-ios/CordovaLibTests, etc.) + * It is recommended to add a short comment to the Jira item stating what testing you did. + * It is recommended that where reasonably feasible, you add automated tests to validate your change and catch any future regressions. + - == Step 4: Ask for a code review == + == Step 6: Ask for a code review == * If you are using a public topic branch, then you should ask for a code review when you consider it to be complete. * Use [[http://reviews.apache.org/|reviews.apache.org]] to create a review request. * By default, the ML will be notified of your review request. * If you have someone in particular that you would like approval from, be sure to add them in "People" field of the review. - == Step 5: Merge your change == + == Step 7: Merge your change == * Once your topic branch is tested & working, it's time to merge it. * Rebase & commit it to master. If it fixes a regression, then also cherry-pick it into the appropriate release branch. * Here is an example workflow for committing a change: @@ -83, +92 @@ Note also that the timestamp on a commit will be unchanged by a rebase, but that it will appear "out of order" in git log. This is because git log is not chronological order, but in order of the `parent` chain of the commits. - == Step 6: Update JIRA == + == Step 8: Update JIRA == Mark the relevant JIRA as fixed, and be sure to include the relevant commit IDs. @@ -92, +101 @@ == Step 1: Review the change == * View the user's branch in github and request changes be made (if applicable) by adding comments in the web interface + * Verify that the contributor tested it, per the test guidelines above. == Step 2: Ensure that they have signed the Contributor Agreement == * For trivial changes, this is not necessary.
