Confirmed users
1,319
edits
Release Management/FirefoxOS/Release Milestones: Difference between revisions
Release Management/FirefoxOS/Release Milestones (view source)
Revision as of 13:15, 11 April 2018
, 11 April 2018move to Archives
(move to Archives) |
|||
| (30 intermediate revisions by 7 users not shown) | |||
| Line 1: | Line 1: | ||
{{RELEASE_MANAGEMENT_OBSOLETE}} | |||
== Firefox OS Release Cycle and Repos == | |||
[[File:Firefox_OS_Release.png|800px|centre]] | |||
<small>Note: Since 2.2, we already increase FL period to 12 weeks. This graphic has to be updated.</small> | |||
A comparison of Firefox and Firefox OS trains: | |||
[[File:Firefox_vs_Firefox_OS_trains.png||centre]] | |||
([https://wiki.mozilla.org/File:Firefox_vs_Firefox_OS_trains.svg SVG source]) | |||
== FEATURE LANDING (FL) == | == FEATURE LANDING (FL) == | ||
Feature Landing (FL) is a fixed milestone in the release schedule. All feature work must be complete by the FL date. | Feature Landing (FL) is a fixed milestone in the release schedule. All feature work must be complete by the FL date. | ||
=== Feature Landing Criteria === | === Feature Landing Criteria === | ||
* Passes functional testing necessary to meet user story acceptance criteria | * QA signoff | ||
* Features must not land with device automated tests disabled | ** Passes functional testing necessary to meet user story acceptance criteria | ||
* No | ** Features must not land with device automated tests disabled | ||
** No smoketest regressions | |||
** MozTrap test coverage must be added for each roadmap feature in a particular release | |||
* No performance or checkerboarding regressions | |||
* Includes integration/unit tests | * Includes integration/unit tests | ||
* Performance/stability metrics maintained at least on par with previous release | * Performance/stability metrics maintained at least on par with previous release | ||
| Line 16: | Line 29: | ||
* Partial landing of a feature may be acceptable | * Partial landing of a feature may be acceptable | ||
** Feature scope change must be signed off by stakeholders including product, UX and QA (may also include other teams like security) | ** Feature scope change must be signed off by stakeholders including product, UX and QA (may also include other teams like security) | ||
=== What if a feature misses the Feature Landing date? === | === What if a feature misses the Feature Landing date? === | ||
* By default the feature is de-scoped from the release and deferred to the next release | * By default the feature is de-scoped from the release and deferred to the next release | ||
| Line 22: | Line 36: | ||
** Acceptance of a late feature delivery may come with conditions such as a target landing date and restrictions to the number of string changes | ** Acceptance of a late feature delivery may come with conditions such as a target landing date and restrictions to the number of string changes | ||
** All features that are to land after FL must first land on master/mozilla-central and have QA sign off on uplift | ** All features that are to land after FL must first land on master/mozilla-central and have QA sign off on uplift | ||
== STRING FREEZE == | |||
* String Freeze marks the beginning of the localization cycle, which includes translation work and translation testing. | |||
* The expectation is that string changes will be landed during the development phase. The target is to land ~90% string changes by FL. | |||
=== What if I need to land string changes after FL? === | |||
* A small number of string changes may be acceptable after FL. | |||
* Tag any bug that requires string changes after FL with the <code>late-l10n</code> keyword. These bugs should be tagged as early as possible. | |||
* String Freeze is targeted for two weeks after FL. <code>late-l10n</code> tagged bugs may land in this two week period. There should be no additional string changes after String Freeze has been declared. | |||
* Options if you find that string changes are required after String Freeze: | |||
** If you have to land minor polish fixes for your feature, land string changes before the String Freeze date and complete your work after the String Freeze date. | |||
** Reuse existing strings in the product instead of adding new ones. | |||
*** This should be done only after having consulted the l10n team, see [https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_best_practices#Don%27t_reuse_strings_in_different_contexts why it is tricky to reuse strings] | |||
** If you need to make a string change after the String Freeze date, speak with release management and l10n about options. | |||
== FEATURE COMPLETE (FC) == | == FEATURE COMPLETE (FC) == | ||
| Line 27: | Line 55: | ||
=== Feature Complete Criteria === | === Feature Complete Criteria === | ||
* All feature landing exceptions must be resolved | * All feature landing exceptions must be resolved | ||
* Bugs with keyword late-l10n should be zero | |||
* Chipset vendor requirements or bugs needed to meet their FC date must be resolved | * Chipset vendor requirements or bugs needed to meet their FC date must be resolved | ||
* QA sign-off | * QA sign-off | ||
** Completed one | ** Completed one functional test run | ||
** | ** QA defines 2 areas of "functional areas" for exploratory testing and lead will send a "signoff" note when he feels its qualitatively ready | ||
** | ** Smoketest Greenness - Latest length of time that we haven't had smoketest regressions needs to be greater than five days | ||
** MTBF Test Run lasts for 30+ hours | |||
* Perfomance team sign-off to ensure we have met the FC ready criteria | * Perfomance team sign-off to ensure we have met the FC ready criteria | ||
'''Notes :''' | '''Notes :''' | ||
| Line 40: | Line 70: | ||
=== Code Complete Criteria === | === Code Complete Criteria === | ||
* No open issues across all user stories | * No open issues across all user stories | ||
* | * Less than 10 valid release blockers. (Additional blockers may be accepted from IOT/certification testing.) | ||
* | * Achieve major chip-set vendor CS milestone. | ||
* Full QA sign-off | * Full QA sign-off | ||
* | ** Target 3 test runs (2 min, 3 max) | ||
* | ** Final test run should >= 98% test case completion | ||
* | ** Test failure % is trending downwards at a healthy level (ie. in 1.3, TR1 = 11%, TR2 = 8%, TR3 = 6%) | ||
** Smoketest Greenness - Latest length of time that we haven't had smoketest regressions needs to be greater than five days. | |||
** QA defines 4-5 areas of “functional areas” for exploratory testing and lead will send a “signoff” note when he feels its qualitatively ready. | |||
** MTBF test run lasts for 100+ hours | |||
* Sign-off from security, stability(MTBF), performance, product | |||
* Support documentation published | |||
* [https://developer.mozilla.org/en-US/Firefox_OS/Releases Release notes] completed and ready to publish | |||
== General Availability (GA) == | == General Availability (GA) == | ||
<span style="color:#FF0000"> '''note: The GA piece is still being worked on with TAM's/partners and should get updated soon''' </span> | <span style="color:#FF0000"> '''note: The GA piece is still being worked on with TAM's/partners and should get updated soon''' </span> | ||
A release is will be declared General Availability (GA) | A release is will be declared General Availability (GA) once the OEM/ODM has completed the IOT/certification testing and granted Terminal Acceptance (TA), which implies the build is good to hit silicon. | ||
=== General Availability Criteria === | === General Availability Criteria === | ||
* Zero blockers for the release - all targeted partner blockers must be fixed. | * Zero blockers for the release - all targeted partner blockers must be fixed. | ||
'''Note : In general, there can be agreed upon exceptions to the above and Release Management will communicate progress on each milestone on all mailing lists (internal, public, partners) effective 2.0''' | '''Note : In general, there can be agreed upon exceptions to the above and Release Management will communicate progress on each milestone on all mailing lists (internal, public, partners) effective 2.0''' | ||
[[category:RelManArchive|FxOS/Cross_Functional/Meetings]] | |||