Release Management/FirefoxOS/2 2 R Schedule

From MozillaWiki
Jump to: navigation, search

This schedule should help outline keydates and milestones for Firefox OS 2.2R. Please reach out to jocheng@mozilla.com for questions or conflict's you may find.


Key milestones and Target Dates

RedSquare:

    • Feature Landing (FL) : Feb 5 2016
    • Feature Complete (FC) : Mar 18 2016
    • Code Complete (CC) : May 6 2016 (should align with CS)

Patch Uplifts

  • IMPORTANT: please do as below flagging so it looks clear to release engineering
    • Add “checkin-needed” keyword.
    • Specify on attachment that certain patch is for 2.2r or master.
    • Need either feature-b2g:2.2r+ or blocing-b2g:2.2r+ tagged for that bug
      • Note: post-FL uplifts would require approval on patches

Criteria for major milestones

FEATURE LANDING (FL)

Feature Landing Criteria

Feature Landing (FL) is a fixed milestone in the release schedule. All feature work must be complete by the FL date.

  • QA signoff
    • Passes functional testing necessary to meet user story acceptance criteria
    • 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 FxOS 2.2

Notes:

  • QA and release management should be informed of all complex feature/Patch landings before the landing occurs.
    • Complex features/patches are defined as:
      • features that have a significant amount of risk wrt destabilizing the tree
      • features that touch multiple modules
  • 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)

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 late-l10n keyword. These bugs should be tagged as early as possible.
  • String Freeze is targeted for two weeks after FL. late-l10n 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.
    • If you need to make a string change after the String Freeze date, speak with release management and l10n about options.

FEATURE COMPLETE (FC)

The Feature Complete (FC) milestone marks the hard cut off date for all feature work related to the current release. In order to declare FC, QA must have completed a set level of testing. Declaring FC indicates the build is ready for chipset vendors to start chipset related testing.

Feature Complete Criteria

  • All feature landing exceptions must be resolved
  • [TBD] Bugs with keyword late-l10n should be zero
  • Chipset vendor requirements or bugs needed to meet their FC date must be resolved
  • No P1 bugs (a. Issues that block tests ex, partner certification, CS blocker. b. Major issues that fail basic functions) exist
  • P2 bugs (Major issues fail basic functions but can be work around) must identified when can be fixed
  • QA sign-off
    • Completed one functional test run
    • Mozilla QA defines 2 areas of "functional areas" for exploratory testing and lead will send a "signoff" note when he feels it's 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 100+ hours
  • Perfomance criteria: AppStartuptime < 1 second

Notes :

  • [TBD] Hard string freeze happens in two weeks as we enter the the FC phase giving the localization team four weeks to localize the strings and prepare for a testrun at FC. FC will typically mark the launch of the initial l10n test run

CODE COMPLETE (CC)

This Code Complete (CC) milestone marks the completion of the release from Mozilla and partner chipset vendors. This is our declaration that we are ready to ship. After this milestone no further Mozilla or chipset vendor specific changes will be accepted. At this point all Mozilla wanted blockers should be resolved leading us to zero blockers. This drop dead date indicates that we are ready to declare a Release Candidate (RC) and Original Equipment Manufacturers (OEM) / Original Device Manufacturers (ODM) can pick our release for their test cycle. The following criteria needs to be met.

Code Complete Criteria

  • No open issues across all user stories
  • Less than 10 valid release blockers.
  • Achieve major chip-set vendor CS milestone.
  • Should provide report supporting following test criteria:
    • 2 full test runs
    • Smoketest Greenness - Latest length of time that we haven't had smoketest regressions needs to be greater than five days.
    • Mozilla 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 800+ hours
    • No performance regression
    • Battery life 7days+
  • Support documentation published
  • Release notes completed and ready to publish
Retrieved from "https://wiki.mozilla.org/index.php?title=Release_Management/FirefoxOS/2_2_R_Schedule&oldid=1102423"