Confirmed users
1,255
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) |
|||
| (11 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
{{RELEASE_MANAGEMENT_OBSOLETE}} | |||
== Firefox OS Release Cycle and Repos == | == Firefox OS Release Cycle and Repos == | ||
[[File:Firefox_OS_Release.png|800px|centre]] | [[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 19: | 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 35: | Line 46: | ||
* 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. | * 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: | * 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. | ** 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. | ** If you need to make a string change after the String Freeze date, speak with release management and l10n about options. | ||
| Line 51: | Line 61: | ||
** QA defines 2 areas of "functional areas" for exploratory testing and lead will send a "signoff" note when he feels its qualitatively ready | ** 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 | ** 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 59: | 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 | ||
* Sign-off from security, stability, performance | ** 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 | * Support documentation published | ||
* Release notes completed and ready to publish | * [https://developer.mozilla.org/en-US/Firefox_OS/Releases Release notes] completed and ready to publish | ||
== General Availability (GA) == | == General Availability (GA) == | ||
| Line 73: | Line 89: | ||
=== 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]] | |||