363
edits
(add a link to "how to request an uplift" page) |
No edit summary |
||
Line 2: | Line 2: | ||
This page describes the rules applied by the Release Team to uplift (aka backport) a patch from a development branch to a more stable branch. For example, taking a patch that fixes a bug in Nightly and applying it to the Beta branch. The [[Release_Management/Tracking_rules|release tracking rules]] page may also be helpful for understanding how release management makes decisions. | This page describes the rules applied by the Release Team to uplift (aka backport) a patch from a development branch to a more stable branch. For example, taking a patch that fixes a bug in Nightly and applying it to the Beta branch. The [[Release_Management/Tracking_rules|release tracking rules]] page may also be helpful for understanding how release management makes decisions. | ||
While uplifts are generally not the preferred way to ship new feature work, it is understood that there are times when business needs to do so justify the required effort. Our release process is designed to have the flexibility to accommodate these requests, though in general they need to be handled on a case by case basis to determine the suitability. Teams are encouraged to reach out to Release Management in the #release-coordination channel on Slack or @relman so their specific needs can be assessed. | |||
Factors that will need to be taken into account include: | |||
* Size and scope of patches to be uplifted | |||
* QA availability to test prior to shipping and during development | |||
* Engineering resources to resolve any conflicts between different development branches | |||
* String additions/changes which may impact available locales | |||
All [https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html regular guidelines] for changes apply. | All [https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html regular guidelines] for changes apply. |
edits