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 for both Gecko and Gaia.

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>

Gaia Uplifts

Git has built-in tools for performing transplants, via the cherry-pick function. Since all Gaia branches live in the same repository, we can use that.

git cherry-pick <rev>

If cherry-picking a pull request merge commit, the -m 1 option must be included. For blame purposes, it is preferable to avoid these commits where possible, however.

git cherry-pick -m 1 <rev>

If the pull request only merged one commit, the parent commit can be cherry-picked. If there were multiple commits contained in the pull request, the merge commit can be used instead. Verify that the commit information such as author is set correctly and adjust using |git commit --amend| if necessary.

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.

B2G

Bug queries are on the B2G Landing page.

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

ESR38

All esr38 approvals not yet uplifted

Fixed intermittents w/o esr38 {fixed|verified|wontfix|unaffected|disabled}