Release Management/B2G Landing: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 220: Line 220:


==== Landing Procedure ====
==== 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:2.0+ or have approval-mozilla-b2g32+ / approval-gaia-v2.0+.
* 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 (<b>including bugs marked as blocking-b2g:1.3+</b>)
** <b>1.4+ blocking bugs need an explicit approval to land on 2.0</b>
** <b>1.4+ blocking bugs need an explicit approval to land on 2.0</b>
** Please use approval-gaia-v2.0? for gaia and approval-mozilla-b2g32? for gecko to request uplift as necessary
** Please use approval-gaia-v2.0? for gaia and approval-mozilla-b2g32? for gecko to request uplift as necessary
* Follow normal landing practices for Trunk/Master.
* Follow normal landing practices for Trunk/Master.
* Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
* Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
* Bugs that are approved for landing on mozilla-beta will be merged to b2g32 as well. <b>There is no need to double-land on beta and b2g32.</b>
* Add a=2.0+ for 2.0 blockers and security bugs or a=<whoever approved> to the end of the commit message and uplift to:  
* Add a=2.0+ for 2.0 blockers and security bugs or a=<whoever approved> to the end of the commit message and uplift to:  
** [https://github.com/mozilla-b2g/gaia/tree/v2.0 v2.0]/[https://hg.mozilla.org/releases/mozilla-b2g32_v2_0 b2g32] (setting status-b2g-v2.0:fixed)
** [https://github.com/mozilla-b2g/gaia/tree/v2.0 v2.0]/[https://hg.mozilla.org/releases/mozilla-b2g32_v2_0 b2g32] (setting status-b2g-v2.0:fixed)

Revision as of 18:28, 2 September 2014

Versions and Scheduling

See also the Rapid Release calendar for B2G.

FFOS Version Scoping Complete (Roadmap updated) Feature Landing (FL){{#info: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 Complete (CC) Underlying Gecko Version
v1.4 ~December 9, 2013 March 17, 2014 Apr 29, 2014 TBD Gecko 30
v2.0 ~Mar 17, 2014 June 09, 2014 July 21, 2014 Sep 01, 2014 Gecko 32
v2.1 ~June 17, 2014 September 01, 2014 October 13, 2014 November 21, 2014 Gecko 34


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

Branch Information

See also B2G/Roadmap.

v1.3.0

Open for approved patches and security 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 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:
    • v1.3/b2g28 (setting status-b2g-v1.3:fixed)
    • v1.4/b2g30 (setting status-b2g-v1.4:fixed) (if necessary)
    • v2.0/b2g32 (setting status-b2g-v2.0:fixed) (if necessary)

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-b2g30+ / approval-gaia-v1.4+.
    • 1.3+ blocking bugs have auto-approval to land on 1.4 if affected and do not need additional approval.
  • 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 1.4 blockers and security bugs or a=<whoever approved> to the end of the commit message and uplift to:
    • v1.4/b2g30 (setting status-b2g-v1.4:fixed)
    • v2.0/b2g32 (setting status-b2g-v2.0:fixed) (if necessary)

Blocker/Approval Queries

v2.0.0

Open for 2.0+ 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+)
    • 1.4+ blocking bugs need an explicit approval to land on 2.0
    • Please use approval-gaia-v2.0? for gaia and approval-mozilla-b2g32? for gecko to request uplift as necessary
  • Follow normal landing practices for Trunk/Master.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=2.0+ for 2.0 blockers and security bugs or a=<whoever approved> to the end of the commit message and uplift to:

Blocker/Approval Queries

v2.1.0

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

Source Repositories

Landing Procedure

  • All blocking-b2g:2.1+ need to seek approval-gaia-v2.1? for gaia and approval-mozilla-aurora? for gecko before landing
  • sec-high and sec-critical patches have automatic approval to land if the fix has landed on all affected Firefox branches.
    • 1.4+/2.0+ blocking bugs need an explicit approval to land on 2.1
    • Until the next target milestone FC for 2.1 which is on Oct 13 2014, if there are any low risk polish fixes that are not blocking but need to land on 2.1, we request you to use approval-gaia-v2.0? for gaia and approval-mozilla-b2g32? for gecko to request uplift as necessary. No guarantees on approval for non-blocking bugs, it may be granted depending on the risk/reward and how far we are in the release timeline
  • Follow normal landing practices for Trunk/Master.
  • Unless the bug only affects that branch, the bug must be Resolved/Fixed before uplifting.
  • Add a=2.1+ for 2.1 blockers and security bugs or a=<whoever approved> to the end of the commit message and uplift to:

Blocker/Approval Queries

Trunk/Master (currently v2.2.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.


Automatic Branch Uplifts

v1.3.0

v1.4.0

v2.0.0

Sanity Checks

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