Sheriffing/How To/Uplifts

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..

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. Git has native cherry-pick functionality that can be used for all Gaia uplifts (or Gecko if using the Git mirror).

Gecko Uplifts

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 (aurora, beta, etc). ***
#   Usage:   hg uplift <source> <rev>
#   Example: hg uplift aurora 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 (aurora, beta, etc). ***
#   Usage:   hg uplift-mq <branch> <bug#> <rev>
#   Example: hg uplift-mq aurora 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!

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>

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. Aurora -> Beta -> etc or v2.2 -> v2.1 -> etc). 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.
  • Until bug 1154728 is resolved, note that Bugherder marks bugs in the *opposite* order of which they landed!
• 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.

Bug Queries

The Release Tracking Report has some useful bug queries. 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"). As a result, a combination of this report and the queries below is recommended to avoid missing bugs.

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).

ESR52

All esr52 approvals not yet uplifted

Best Practice

• Use a unified tree https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos can help you with that
• Use the queries from release_tracking_report to find Bugs to uplift as example

as example "show where approval-mozilla-aurora was changed to approval + between - use custom dates 
set the current status of the current aurora version as unfixed like status mozilla-51 not fixed

• Use the Resulting Bugs to uplift

• If you have patches like a rebased - aurora patch where a straight uplift from mozilla-central to like aurora don't work see https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos#Single_repository_and_single_set_of_patches

• 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