Release Management/FirefoxOS/Release Milestones

Note : This page is WIP --Bhavana (talk) 22:15, 22 April 2014 (PDT)Italic text

Firefox OS Release Cycle and Repos

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
• Features must not land with device automated tests disabled
• No smoke-test, performance or checkerboarding regressions
• Includes integration/unit tests
• Performance/stability metrics maintained at least on par with previous release

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)

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
• Exceptions can be granted based on criteria such as business need, % feature work completed and expected delivery date, and risk of backing out or preffing off.
• 1-2 weeks before the FL date the Engineering Project Mangers (EPMs) will prepare the list of outstanding features and the release manager, release owner, a product rep, and a QA rep will review the outstanding feature list and make a decision about whether each feature that is at risk of missing FL will remain in the target release or be de-scoped
  • 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

String Freeze

String Freeze marks the beginning of the localization cycle, which includes translation work and translation testing.

Soft String Freeze

Soft String Freeze is the target for all strings to be finalized. This milestone is described as soft because a small number of exceptions can be granted after this date.

Note:

• Any bug with string changes that are targeted to land after FL must be flagged with the late-l10n keyword.

Hard String Freeze

Hard String Freeze is the last date that string changes can be accepted in a release. No exceptions will be granted after this date.

What if my work misses the String Freeze dates?

• No string changes will be accepted after Hard String Freeze. UI work may need to be deferred to another release.
• Alternative options:
  • Reuse existing strings in the product instead of adding new ones.
  • Land string changes before the String Freeze date and complete your work after the String Freeze date.

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. FC is a flexible milestone with a target date. FC will only be declared when all of the FC criteria have been met.

Feature Complete Criteria

• 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
• QA sign-off
  • Completed one end-end test run
  • Covered all the functional and regression testing areas
  • Covered any special exploratory testing that may be needed by a special feature targeted in that release
• Perfomance team sign-off to ensure we have met the FC ready criteria

Notes :

• 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
• Zero mozilla driven blockers. (Additional blockers may be accepted from IOT/certification testing.)
• Zero chipset vendor driven blockers.
• Chipset vendor sign-off for OEM/ODM to begin testing
• Full QA sign-off
• Sign-off from security, stability, performance, marketplace, content, product, SUMO
• Support documentation published
• Release notes completed and ready to publish

General Availability (GA)

note: The GA piece is still being worked on with TAM's/partners and should get updated soon

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

• 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