Personal tools

Release Management/B2G Landing

From MozillaWiki

Jump to: navigation, search

Contents

Versions and Scheduling

FFOS Version Scoping Complete (Roadmap updated) Feature Landing (FL)Feature Landing (FL) is a fixed milestone in the release schedule. All feature work should be complete by the FL date Feature Complete (FC) Code Freeze (CF) Underlying Gecko Version
v1.4 ~December 9, 2013 March 17, 2014 Apr 29, 2014 June 09, 2014 Gecko 30
v2.0 ~Mar 17, 2014 June 09, 2014 July 21, 2014 Sep 01, 2014 Gecko 32


Previous Releases

FFOS Version Scoping Complete Functional Complete (FC) Code Freeze (CF) Underlying Gecko Version Included Gecko Security Fixes Blocking bug notation End-of-life (EOL)
v1.0 (obsolete) n/a Dec 22, 2012 January 2013 Gecko 18 Gecko 18 blocking-basecamp:+, blocking-b2g:tef+ -
v1.0.1 n/a Jan 15, 2013 May 2013 Gecko 18 Gecko 20 blocking-b2g:tef+, blocking-b2g:shira+ -
v1.1.0 n/a Mar 29, 2013, with MMS/CBS/Auto-Correct waived July 2013 Gecko 18+ (new APIs) Gecko 23 blocking-b2g:leo+ March 17, 2014
v1.1.0hd n/a TBD TBD Same as 1.1.0 (merged automatically), with wvga Same as 1.1.0 blocking-b2g:hd+ March 17, 2014
v1.2.0 June 24, 2013 Sep 16, 2013 December 9, 2013 Gecko 26 Gecko 26 blocking-b2g:koi+ June 09, 2014
v1.3.0 September 16, 2013 December 9, 2013 March 3, 2014 March 17, 2014 Gecko 28 Gecko 28 blocking-b2g:1.3+ September 01, 2014


See the triage wiki page for more info about remaining blocking bugs. See this picture for an explanation of early branching (updated soon). See bug 829451 for an explanation of the version scheme.

Rough Update Graph

  • Q3 2013
    • 1.0.1 Released
  • Q4 2013
    • 1.1 Released, OEMs will update 1.0.1->1.1
  • Q1 2014
    • 1.2 Released, OEMs will update 1.1->1.1.1/2 or 1.1->1.2
  • Q2 2014
    • 1.3 Released, OEMs will update 1.1.1->1.2.1/2, 1.2->1.2.1/2, 1.1.1->1.3, or 1.2->1.3
  • Q3 2014
    • 1.4 Released, OEMs will update 1.2.1->1.3.1/2, 1.3->1.3.1/2, 1.2.1->1.4, or 1.3->1.4

Nominating Issues

See https://wiki.mozilla.org/B2G/Triage

All about approval flags

see https://wiki.mozilla.org/Release_Management/Uplift_rules

Feature Landing Criteria

  • Passes functional testing necessary to meet acceptance criteria
  • Features must not land with device automated tests disabled
  • No smoke-test, performance or checker boarding regressions
  • Includes integration/unit tests for features
  • Performance/ stability metrics maintained at least at par with previous release
  • QA and release management must be informed of all complex feature landings before the landing occurs.
    • Complex features:
      • features that have a significant amount of risk wrt destabilizing the tree
      • touches multiple modules
  • NOTE: Partial landing of features is accceptable if they pass requisite tests and acceptance criteria
    • Acceptance criteria met before being verified fixed by QA
    • Acceptance criteria should include all necessary signoffs by UX, security,product and QA.

Work Order

  • 1.3+
  • 1.3T+
  • 1.4+
  • stabilization work for 1.4
  • other non-blocking/stabilization work for 1.4/1.5

Branch Information

See also B2G/Roadmap.

v1.1.x (including hd)

Open for critical security fixes only.

Source Repositories

Landing Procedure

  • Only patches explicitly approved by B2G Release Management may land.
  • Follow normal landing practices for Trunk/Master.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=<whoever approved> to the end of the commit message and uplift to:
  • Any patches landed on v1.1 will be merged by the sheriff team to the v1.1hd branch as well.

v1.2.0

Open for koi+ blockers and approved security/stability fixes only.

Source Repositories

Landing Procedure

  • sec-high and sec-critical patches have automatic approval to land if the fix has landed on all affected Firefox branches. All others must be blocking-b2g:koi+ or have approval-mozilla-b2g26+ / approval-gaia-v1.2+.
  • Follow normal landing practices for Trunk/Master.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=1.2.x+ for security bugs, a=koi+ for blockers, or a=<whoever approved> to the end of the commit message and uplift to:

Blocker/Approval Queries

v1.3.0

Open for 1.3+ blockers, approved patches, and security fixes.

Source Repositories

Landing Procedure

  • sec-high and sec-critical patches have automatic approval to land if the fix has landed on all affected Firefox branches. All others must have approval-mozilla-b2g28+ / approval-gaia-v1.3+ to land (including bugs marked as blocking-b2g:1.3+).
  • Follow normal landing practices for Trunk/Master.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=1.3+ for security bugs or a=<whoever approved> to the end of the commit message and uplift to:

Blocker/Approval Queries

v1.3T

Open for 1.3T+ blockers.

Source Repositories

Landing Procedure

  • Patches must have blocking-b2g:1.3T+ to land.
  • Follow normal landing practices for Trunk/Master unless the but only affects the v1.3T branch.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=1.3T+ to the end of the commit message and uplift to:
  • Bugs that also affect v1.4 (status-b2g-v1.4:affected) will be handled on a case-by-case basis for uplift. Due to the specialized nature of this branch, 1.3T+ blocking status does not grant automatic approval to uplift to v1.4. Patches must go through the regular approval process as detailed below for v1.4 consideration.
  • The v1.3 repos (b2g28 / v1.3) are regularly merged by sheriffs to the v1.3t branches. Patches with v1.3 approval should not be double-landed on the two branches.

Blocker/Approval Queries

v1.4.0

Open for 1.4+ blockers, approved patches, and security fixes.

Source Repositories

Landing Procedure

  • sec-high and sec-critical patches have automatic approval to land if the fix has landed on all affected Firefox branches. All others must be blocking-b2g:1.4+ or have approval-mozilla-aurora+ / approval-gaia-v1.4+.
  • To request a gaia approval on any bug, set : approval-gaia-v1.4: ? along with filling in all the details requested in approval request comment

Note If a gaia bug is blocking 1.3+, the approval-gaia-1.3: ? should be enough to consider the reqeust on 1.3 and 1.4 branch. You do not need an explicit approval request for the 1.4 landing.

  • To land a gecko related patch, please request approval-mozilla-aurora: ?, filling in the approval request comment.
    • Release Management team should get to these approvals in a day or two. For any urgent landings or immediate attention, feel free to NI:release-mgmt@mozilla.com
  • Follow normal landing practices for Trunk/Master.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=1.4+ for security bugs or a=<whoever approved> to the end of the commit message and uplift to:
    • v1.4/aurora (setting status-firefox30:fixed and/or status-b2g-v1.4:fixed)

Blocker/Approval Queries

Trunk/Master (currently v2.0.0)

Open for any feature work and bug fixes.

Source Repositories

Landing Procedure

  • r+ is required
  • For Gaia patches, land on master or set the checkin-needed bug keyword and it will be landed for you. Once landed, the bug should be marked RESOLVED FIXED.
  • For Gecko patches, land on b2g-inbound or set the checkin-needed bug keyword and it will be landed for you.
    • b2g-inbound is regularly merged by the sheriffs to mozilla-central.
    • Bugs are automatically resolved once merged to mozilla-central.

Blocker/Approval Queries

Automatic Branch Uplifts

v1.1.x (including hd)

v1.2.0

v1.3.0

v1.4.0