Release Management/FirefoxOS/Release Milestones: Difference between revisions

← Older edit

Release Management/FirefoxOS/Release Milestones (view source)

Revision as of 13:15, 11 April 2018

1,113 bytes added , 11 April 2018

move to Archives

Pascalc

Confirmed users

1,255

edits

@@ 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>
-'''Note : This page is WIP --[[User:Bhavana|Bhavana]] --[[User:Bhavana|Bhavana]] ([[User talk:Bhavana|talk]]) 18:27, 28 April 2014 (PDT)'''''Italic text''
+A comparison of Firefox and Firefox OS trains:
-== Firefox OS Release Cycle and Repos ==
-[[File:Firefox_OS_Release.png|800px|centre]]
+[[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) is a fixed milestone in the release schedule. All feature work must be complete by the FL date.
 === 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 smoke-test, performance or checkerboarding regressions
+** 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
 * Performance/stability metrics maintained at least on par with previous release
@@ Line 22: / Line 29: @@
 * 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)
 === 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
@@ Line 38: / 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.
 * Options if you find that string changes are required after String Freeze:
-** Land string changes before the String Freeze date and complete your work after the String Freeze date.
+** 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.
-*** Note: Text may be translated differently based on context. Ensure that the strings that you are to use fit in the context.
+*** 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]
-*** Seek the l10n team's advice as needed.
 ** If you need to make a string change after the String Freeze date, speak with release management and l10n about options.
@@ Line 51: / Line 58: @@
 * Chipset vendor requirements or bugs needed to meet their FC date must be resolved
 * QA sign-off
-** Completed one end-end test run
+** Completed one functional test run
-** Covered all the functional and regression testing areas
+**  QA defines 2 areas of "functional areas" for exploratory testing and lead will send a "signoff" note when he feels its qualitatively ready
-** Covered any special exploratory testing that may be needed by a special feature targeted in that release
+** 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
 '''Notes :'''
@@ Line 62: / Line 70: @@
 === Code Complete Criteria ===
 * No open issues across all user stories
-* Zero mozilla driven blockers. (Additional blockers may be accepted from IOT/certification testing.)
+* Less than 10 valid release blockers. (Additional blockers may be accepted from IOT/certification testing.)
-* Zero chipset vendor driven blockers.
+* Achieve major chip-set vendor CS milestone.
-* Chipset vendor sign-off for OEM/ODM to begin testing
 * Full QA sign-off
-* Sign-off from security, stability, performance, marketplace, content, product, SUMO
+** 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
-* 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) ==
@@ Line 76: / Line 89: @@
 === General Availability Criteria ===
 * 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'''
+[[category:RelManArchive|FxOS/Cross_Functional/Meetings]]