Release Management/FirefoxOS/Release Milestones

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

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 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

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
• 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
• Perf 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
• Release Management to get a sign-off from all parties here, may be a week before
  • Security, stability, perf, QA, marketplace, content, product, SUMO, etc
• Complete all on-line documentation (including SUMO articles, release notes, help etc)
• Communication with partner on availability of this Release

General Availability (GA)

A release is will be declared General Availability (GA) Ready 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: the GA piece is still being worked on with TAM's/partners and should get updated soon

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