Sheriffing/How To/Uplifts

From MozillaWiki
Jump to: navigation, search

Standard practice is that bug fixes that affect the release branches must first land on trunk/master. Unless there is a branch-specific patch attached to the bug, the patch that landed must then be transplanted to the appropriate branches. This page documents the procedure for performing those uplifts.

Bug Queries

The Release Tracking Report has bug queries which can find the bugs which needed to be uplift to mozilla-beta or mozilla-release. However, it has limitations in that it only sees bugs that have a status of "affected", "fixed", or "verified" set. As a result, it will miss approved bugs if no status is set ("---") and will show bugs as still needing uplift if their status is an unexpected value (like "disabled").

Bugs which don't need approval to get uplifted because they don't modify the build - e.g. test fixes - have the string checkin-needed-beta in the whiteboard and can be listed with this query.

Filter the bugs, using the following steps (example for mozilla-beta):

  • Set the dropdown with "approval-mozilla-*" to "approval-mozilla-beta".
  • The status dropdown has to be changed from "?" (approval requested) to "+" (approval granted).
  • Set a date range in which the approval was granted. Usually the last week is sufficient, only when something got approved and backed out later and the update of the patch with the fix takes longer than usual, a longer time frame will be needed. To check the whole date range for that release cycle, start with the last merge date from the release calendar.
  • Set the status status-firefoxNN to not fixed - NN is the version number used for beta: 1 less than the version number on Nightly. Check the release calendar to find the version number for the current beta version. Same version number for beta and release.
  • Run the search.

Sheriffing uplift query.jpg

The query will return the list of bugs needing uplift. To prevent unnecessary conflicts during the uplift process, the bugs and their patches shall be uplifted in the order like they landed on the tree from which they are grafted. For mozilla-beta that is from mozilla-central and can be achieved like this:

  1. Go to the bottom of the list with bugs pending uplift.
  2. Click 'Change Columns'.
  3. In the left list of 'Available Columns', find 'Closed' (= last time the bug got set to 'RESOLVED').
  4. Move it to the right list of 'Selected Columns' and save it.
  5. Sort the bug list by Closed.
  6. Uplift the bugs which landed on mozilla-central.
    • Check what attachments have approval-mozilla-beta+
    • Check if attachments are written for beta and haven't landed on mozilla-central: They will have 'beta' or similar in the attachment name.
    • Find the comment in which the developer requested the uplift.
      1. Check the attachment for which the request was made (at the top of the request).
      2. Scan the request for other bugs which have to land together with this one.
      3. Read the response of the release manager for any clarifications what needs to be done.
    • If a patch landed on central and is also need for beta, use hg graft -r revision
    • If it's a patch written for beta, import it with Phabricator. If it's a plain text patch, use hg import linktopatch.
  7. Bugs not yet resolved should be managed after the resolved ones.
    • If they are supposed to land on mozilla-central and haven't done so yet, skip the uplift until they did unless there are specific instructions to do otherwise.

ESR

The ESR intermittent queries are *very* useful for looking at recently-fixed intermittent failure bugs and ensuring that status flags are set for all applicable releases. The Release Calendar can help determine in which release an intermittent first appeared (in addition to looking at Treeherderbot comments in the bug).

ESR60: All esr60 approvals not yet uplifted

ESR68: All esr68 approvals not yet uplifted

Prerequisites

To perform uplifts with Mercurial, either the native graft command or the transplant extension needs to be enabled, depending on how the different branches are cloned.

Gecko Uplifts

Using A Unified Repository

When using the Firefoxtree extension, all the Gecko releases live in the same repository. The native graft function can be used. 

hg graft -er <rev>

It's recommend to only uplift 10-12 bugs per bug to keep identification of the root cause of new failures easy.

Example:

  1. hg pull beta
  2. hg update beta
  3. Identify what needs to be uplifted and if it is in upliftable state (e.g. didn't get already backed out). Find the comment in which the developer requested uplift. Read it. Check for List of other uplifts needed for the feature/fix. "None" is fine but if other bugs are mentioned, they should be landed first (but they also require approval to get uplifted).
  4. If the bug has multiple patches or revisions and uplift hasn't been requested for all of them, read the comments and commit messages to identify if all need uplift.
  5. Check if the attachment for which the approval was granted is the same like the one which landed on mozilla-central. If no, import the attachment similar to a patch which gets landed on mozilla-inbound. If yes, in the bug find the commits to mozilla-central which didn't get backed out (can be multiple commits/comments, e.g. if follow-ups got used).
  6. Run hg graft -er <revision>
    • If there are multiple revisions directly committed after one another, use hg graft -er <older revision>::<newer revision>
    • If there are multiple revisions not directly committed after one another (e.g. from different bugs), use hg graft -er <revision>+<revision>
  7. Edit the commit message adding the approver: a=<whoever approved the review>. If the patch got imported, also check the bug number, format, commit message and user and email address.
  8. Check what will get pushed: hg out -r . beta
  9. If everything is okay, push to the server: hg push -r . beta
  10. On Treeherder, go to the push and mark it with Bugherder.

Sheriffing uplifts bug update.jpg


Note:If someone pushed to beta before you, you must rebase:

  1. hg pull beta
  2. hg rebase -d beta
  3. check changes: hg out -r . beta
  4. if everything looks good: hg push -r . beta



If you want to uplift and there is no revision to graft, import the patches as usual and push to beta - similar to landing patches on inbound, except that you land them on beta. See landing patches - just replace the repository name: Inbound with Beta.


Example: Let's say we have this bug from the Release Tracking Report: https://bugzilla.mozilla.org/show_bug.cgi?id=1354332. Looking through the comments, we are checking for the mozilla-central revision marked by Bugherder, and it is https://hg.mozilla.org/mozilla-central/rev/034443b19f2b

  • hg pull beta
  • hg update beta
  • hg graft -er 034443b19f2b
  • add a=gchang as the one that approved the review: (gchang : approval-mozilla-beta+), so the commit message will be: "Bug 1354332 - Update the tab bar layout when the UI density changes. r=johannh a=gchang"
  • hg push -r . beta
  • mark the push with Bugherder
Uplift.png

Using Separate Repositories

By default, the different Gecko branches live in different repositories. With multiple repos, the transplant extension is the preferred method. Creating an alias simplifies the process for transplanting a given revision (or revset). 

# Transplant a cset from the specified branch to the current branch and edit the commit message.
# *** This assumes that local clones are named mozilla-XXX (central, beta, etc). ***
#   Usage:   hg uplift <source> <rev>
#   Example: hg uplift central abc123abc123
uplift = transplant -e -s ../mozilla-$1 $2

Optionally, an mq-based alias can also be created, which exports a specified revision from the current clone and imports it into another. 

# Export a cset from the current branch to the specified branch, add it to the queue, attempt to apply it, and edit the commit message.
# *** This assumes that local clones are named mozilla-XXX (central, beta, etc). ***
#   Usage:   hg uplift-mq <branch> <bug#> <rev>
#   Example: hg uplift-mq central 123456 abc123abc123
uplift-mq = !hg export -r $3 > ../mozilla-$1/.hg/patches/$2 && cd ../mozilla-$1 && hg qimport -e -P $2 && hg qref -e

NOTE: The above aliases work in opposite directions!

Uplift Procedure

  • Unless specifically cleared by Release Management, patches should land on mozilla-central prior to being uplifted elsewhere.
  • Patches should be uplifted from the most-recent version to the oldest (i.e. central -> Beta -> release -> ESR). This will help minimize rebasing pain.
  • To avoid conflicts, patches should be transplanted from oldest to newest. The search queries below default to sorting in the order the bugs were resolved.
  • If there is a branch-specific patch attached to the bug, use that. Otherwise, transplant it using the methods shown in the section above.
  • Add a=<whoever approved> to the commit message.
  • After pushing, mark the bugs and set the appropriate status flags. The Bugherder tool available from the dropdown on the right side of each push on Treeherder can automate this process.

Best Practice

as example "show where approval-mozilla-beta was changed to approval + between - use custom dates 
set the current status of the current beta version as unfixed like status mozilla-51 not fixed
  • Use the Resulting Bugs to uplift
  • As example for a beta uplift from mozilla-central
 Pull and update to prepare for the uplifts:
   hg pull central
   hg pull beta
   hg up beta

Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
hg graft --edit -r <revision>

Repeat the previous step as needed for all uplifts as needed. Verify the outgoing changes and push:
hg out -r . beta
hg push -r . beta
Retrieved from "https://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Uplifts&oldid=1231840"