Uplifting Fixes
Some fixes are more urgent than others and "riding the train" will take too long to get the fix to users. This is where uplifts come into play. Uplifts allow a fix to be fast-tracked into the Beta, Release, or ESR channels.
Uplifts to Beta
Uplifts to Beta are limited to bug and security fixes only. Features and enhancements will be included in the next merge.
Patches nominated for uplift to Beta should:
Be limited to bug and security fixes.
Have already landed on comm-central.
Have been tested and stabilized on comm-central.
Include tests or provide a strong justification for the absence of tests.
Not change any localizable strings.
Uplifts to Beta can include:
Proven performance improvements.
Top crash fixes.
Security fixes.
Fixes for recent regressions.
Low-risk improvements early in the Beta cycle.
Uplifts to Release and ESR
Uplifts to Release and ESR are limited to stability and security fixes only. Features and enhancements will be included in the next merge.
Patches nominated for uplift to Release or ESR should:
Be limited to stability and security fixes only.
Have already landed in comm-beta.
Have been tested and stabilized on comm-beta.
Include tests or provide a strong justification for the absence of tests.
Not change any localizable strings.
Uplifts to Release and ESR can include:
Major top crash fixes.
High volume startup crash fixes.
Security fixes.
Fixes for regressions with a broad impact.
Fixes for problems in a major feature.
Process for Uplifts
Requesting an uplift is done by setting the relevant flag (approval-comm-beta, approval-comm-release, or approval-comm-esr) on a Bugzilla patch attachment to ?. The Uplift Request Form (see below) is automatically generated to provide the required information. All uplifts must use the Uplift Request Form.
Ensure uplift requests are submitted at least two working days prior to any scheduled release date. This will allow the release team to build the release the day before the scheduled release date, giving ample time for troubleshooting and testing prior to release day.
Uplift Request Form
Please state case for uplift consideration and ensure bug severity is set
User impact if declined
Provide details on how an end user would be impacted with or without this change. In addition to the Steps to Reproduce (STR), explain the deeper implications for users.
Is this code covered by automated tests?
Options: Yes / No / Unknown
Has the fix been verified in Daily?
Options: Yes / No / N/A
Has the fix been verified in Beta?
Options: Yes / No / N/A
Needs manual test from QA?
Options: Yes / No
If "Yes," include the steps to reproduce either by referencing an existing comment with STR or elaborating directly.
List of other uplifts needed
If this patch depends on other changes not present on the target branch, list those dependencies here.
Ensure approval is also requested for dependent patches.
Risk to taking this patch
Options: Low / Medium / High
Provide a justification as to why the benefits of the uplift outweighs the associated risks.
Examples:
Low: A one-line CSS change impacting only the settings page.
Medium: Due to code complexity and integration with other areas, there might be regressions in related functionality.
High: The patch involves complex changes with a high likelihood of fallout or regressions, which may require extensive manual testing or mitigation strategies.
Why is the change risky/not risky? (and alternatives if risky)
If the change is risky, explain the potential impact. In other words, describe the potential negative impacts that could occur if the change leads to a regression. What mitigations were taken to reduce the risk? What alternative solutions were considered?
String changes made/needed
Answer "none" if no string changes were made.
If there are string changes, add details and justification to help with l10n review.
Last updated
Was this helpful?