Confirmed users
425
edits
No edit summary |
|||
Line 70: | Line 70: | ||
## This can also be done by pasting the url to the Github pull request into an attachment to the bug using 'paste text as attachment'. | ## This can also be done by pasting the url to the Github pull request into an attachment to the bug using 'paste text as attachment'. | ||
## Flag the attachment for review and add a comment that this patch is to uplift to the branch of interest. | ## Flag the attachment for review and add a comment that this patch is to uplift to the branch of interest. | ||
== Reviewing and Merging Uplifts == | |||
Often a pull request which is an uplift from master to a branch of interest will contain code that is identical to that which was committed to master. That code has already been reviewed for correctness and style, so it may not be necessary to review the code itself as carefully. You will need to determine whether that is the case yourself. You could do that by comparing the files changed, after applying the commit in the pull request, with the same files in the master branch. | |||
Regardless of the decision made above, before merging the code: | |||
# Any affected tests should be run against the branch in question. | |||
# A passing Travis build of the pull request should have completed. | |||
## If the Travis build failed check it to see if the ''gaia_ui_tests'' step failed, and if it did whether any of the affected tests failed. Although it is preferred that no pull request be merged with a failing Travis build, if you are confident that the Travis failure had nothing to do with the changes in your pull request you may merge it, at your own discretion. | |||
## You may also request a rerun of the Travis build, which you do via the [https://travis-ci.org/mozilla-b2g/gaia/pull_requests Travis UI], if you would prefer to see it pass before merging. | |||
== Keeping On Top of Changes == | == Keeping On Top of Changes == |