Confirmed users
169
edits
Partnering/Addons/Process: Difference between revisions
outline uplift and gofaster process for partners
Mixedpuppy (talk | contribs) (Created page with "= Releasing Partner supported features in Firefox = This document outlines how we will co-produce and ship new features in Firefox based on partner functionality. It focuses...") |
Mixedpuppy (talk | contribs) (outline uplift and gofaster process for partners) |
||
| Line 73: | Line 73: | ||
# branch is cloned to forked repositories for work | # branch is cloned to forked repositories for work | ||
# changes are pulled back to the main repository via pull requests | # changes are pulled back to the main repository via pull requests | ||
# Addon should be uploaded to AMO for an AMO review | |||
# once the AMO review is complete, create a pull request | |||
# pull requests are reviewed by mozilla staff, once accepted are merged into | # pull requests are reviewed by mozilla staff, once accepted are merged into | ||
# the main repository. | # the main github repository. | ||
# when ready, branch is merged to master in the main repository | # when ready, branch is merged to master in the main repository | ||
| Line 111: | Line 113: | ||
Firefox is developed following a train model where each release will go through development (aka Nightly on mozilla-central), alpha (aka Aurora or Dev Edition), beta then release. Each phase is roughly a 6 week period though adjustments are made periodically for seasonal reasons (e.g. December holiday seasons). We maintain a handy [[RapidRelease/Calendar|Release Calendar]] you can refer to for a detailed and updated schedule. | Firefox is developed following a train model where each release will go through development (aka Nightly on mozilla-central), alpha (aka Aurora or Dev Edition), beta then release. Each phase is roughly a 6 week period though adjustments are made periodically for seasonal reasons (e.g. December holiday seasons). We maintain a handy [[RapidRelease/Calendar|Release Calendar]] you can refer to for a detailed and updated schedule. | ||
It is expected that system addons will typically ride this train, requiring a full 18 week schedule prior to release. Under some agreements that schedule will be shortened to provide a quicker release cycle. Testing and review processes may be more stringent in this case, and is outlined under the GoFaster program. [Google doc, to be | It is expected that system addons will typically ride this train, requiring a full 18 week schedule prior to release. Under some agreements that schedule will be shortened to provide a quicker release cycle. Testing and review processes may be more stringent in this case, and is outlined under the GoFaster program. [https://docs.google.com/document/d/1x27I7hAmWDWiqk3o3YC3fklhE3N59bdgHCQHF5p_lkU GoFaster Google doc] | ||
== Test Pilot == | |||
[TBD] | |||
== AMO Release Channel == | |||
Add-ons released via [https://addons.mozilla.org AMO] can be used as an alternative distribution channel. The addon should maintain the same versioning and addon id as what is distributed in the Firefox release. This will allow the addon to replace the builtin system addon. If the AMO version is removed, the builtin system addon will be reenabled. It is preferable that this is only used for releasing beta versions of the addon, or as a testing mechanism with a subset of users. | |||
== GoFaster Release Channel == | |||
The GoFaster program provides a process by which a system addon can be uplifted faster than the regular Firefox release schedule. This can be used to fast track new features and/or critical bug fixes. It is still preferable to let new features settle on the Firefox Beta channel prior to release. GoFaster is relatively new with only limited internal use at the time of this writing, therefore the process is subject to change as we refine the process. | |||
=== Uplift to Beta === | |||
For non critical fixes we will require some stabilization time prior to uplift. This helps ensure a quality release for Firefox. Since changes have been reviewed via AMO and the github pull requests, only a cursory review if any should be necessary at this point. You should be familiar with the [[Release_Management/Feature_Uplift|uplift criteria]], though your partner engineering contact should help you changes get through the process. | |||
Criteria: | |||
* Changes must uplift prior to Beta 6 | |||
* Changes must stabilize on nightly and aurora prior to beta uplift | |||
* All changes must be final prior to uplift | |||
* Critical fixes may land during or after Beta 6, these will require additional scrutiny by the release management team. | |||
Process: | |||
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=General Create a new bug] for the addon under the Firefox product using the General category. [NOTE: We will find a better product/component combination] | |||
** example subject: merge release of ABC system addon | |||
** example description: | |||
ABC is ready to release a new version of it's addon. | |||
The partner repository is located at https://github.com/mozilla-partners/ABC . | |||
Please land the updates into nightly using the git tag "1.0.2". | |||
** Include a summary of changes in the description | |||
** Create an attachment with a link to the diff on github. The attachment in bugzilla is necessary for uplift requests. | |||
* Once the changes have landed into nightly (mozilla-central repository) let the changes sit for 2-5 days. Then you may [[Release_Management/Feature_Uplift|request uplift]] to Aurora and Beta. | |||
** edit the attachment and add the approval‑mozilla‑aurora? and approval‑mozilla‑beta? flags (setting both to ?) | |||
** Fill in the form that has been added to the comment field. | |||
** Release engineers will see the flags and approve or ask additional questions. | |||
=== Uplift to Release Channel === | |||
Uplifting changes to the release channel should be a last resort, reserved for critical fixes, unless the changes are otherwise part of a plan in coordination with Mozilla. A partner engineer will assist with the release uplift process. | |||
Process: | |||
* Changes must have already gone through the above uplift process and should be on the Beta channel. | |||
* “Intent to ship” bug should be created in Bugzilla [TBD product/component for bug?]. The bug should link to all bugs, issues and patches related to the version of the addon that will ship to release. | |||
* Partner Engineering will send an intent to ship email to the release drivers (see [https://docs.google.com/document/d/1x27I7hAmWDWiqk3o3YC3fklhE3N59bdgHCQHF5p_lkU gdoc] for details). | |||
** Uplift request made by Partner Engineering (mozilla-approval-release = “?”) | |||
** Uplift approval made by Release Management [RelMan] (mozilla-approval-release = “+”) | |||
** relnote-firefox tracking flag set by dev with suggested wording for relnote | |||
* Dev and QA will test changes | |||
* QA confirms changes on Beta channel | |||
* RelMan schedules release | |||
* Partner Engineering will push the change by landing the code in moz-release branch and balrog configuration change. | |||
* The release will start with a throttled rollout to 10% of users. | |||
* The release will push to 100% of users after 24-48 hours with no regressions. | |||
* If necessary, Communications will publish information about the update after the update has been unthrottled. | |||