Release Management/B2G Landing

From MozillaWiki
Jump to navigation Jump to search

Versions and Scheduling

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
v1.4.0 December 9, 2013 March 17, 2014 June 09, 2014 Gecko 30 Gecko 30 blocking-b2g:1.4+ November 24, 2014
v1.5.0 ~March 17, 2014 June 09, 2014 Sep 01, 2014 Gecko 32 Gecko 32 blocking-b2g:1.5+ TBD


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

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
  • Partial landing of features is accceptable if they pass requisite tests and acceptance criteria
    • Acceptance criteria before being verified fixed by QA
    • Acceptance criteria should include all necessary UX, security,product and QA signoffs as needed by the feature in question

Form to be filled while seeking approval via flags

[Approval Request Comment]

  • Bug caused by (feature/regressing bug #):
  • User impact if declined:
  • Testing completed: attach test results
  • Risk to taking this patch (and alternatives if risky):
  • String or UUID changes made by this patch:
  • Performance impact: provide test results

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.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
  • 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 v1.5.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

Retrieved from "https://wiki.allizom.org/index.php?title=Release_Management/B2G_Landing&oldid=959678"