B2G/Triage

This page is a rollup of all the bug queries floating across the B2G project. This will include Gonk, Gaia, Gecko, and Marketplace.

Triage responsibility and landing target

FxOS Core Group

• Before feature complete date, FxOS functional teams are in development and stabilization stages. Each functional team should cover the triage process.
• After feature complete date, release management team handles release based triage process.
• After platform branches are created, FxOS device group(TAMs, EPMs and EMs) drives the triage process on bugs that are reported for platform launches.
• Blocking-b2g flag indicates where the fixes should be landed to:
  • If a bug matches the blocking criteria, it will be tagged with blocking-b2g:version#+ value(for example, blocking-b2g:2.1+). Fixes will go to corresponding version branch and master / mozilla-central.
  • Otherwise, it should be minus'ed and fixes only go to master / mozilla-central.

FxOS Device Group

• The triage process is handled by FxOS device group. To plus them or not is decided based on the influence on device launches.
• Blocking-b2g flag indicates where the fixes should be landed to. And, it depends on:
  • If we can reproduce bugs with reference device or not.
    • If yes, blocking-b2g flag should be set to the values for FxOS core group(for example, 2.0+, 2.1+, ...). Fixes should go to specific version branches and master / mozilla-central.
    • Otherwise, it should be set with values for FxOS device group(for example, 2.0M+, 2.0S+, …). It means, the bugs only affect platform specific launches. We will tag keywords(ex, "[2.0M_Only]") in the whiteboard and fixes only go to 2.0M branch.
  • If the fixes are urgent to be landed for some reasons, these blocking-b2g flags should be device group specific values(for example, 2.0M+, 2.0S+, …).
    • If the bugs only affect platform specific launches, we will tag keywords(ex, "[2.0M_Only]") in the whiteboard and fixes only go to 2.0M branch.
    • Otherwise(to 2.1), fixes will go to platform branches "and" master / mozilla-central as well.
• After device group identified a bug as a device blocker, device group will configure the blockers to block a device launch meta bug(for example, Woodduck_Blocker meta bug).
• Tracking flag(for example, status-b2g-v2.0M) is marked as "affected" once we identify that platform launches are affected by this bug.
• Once a bug is tagged as a blocker(blocking-b2g:release#+), FxOS core group shouldn't minus it, due to its urgency and importance on device launches.
• So, overall, the tagging rule after triage driven by device group is(take 2.0M as an example):

Tagging rule	Description	Landing to master/m-c	Landing to 2.0	Landing to 2.0M
linked to Woodduck_Blocker meta bug; blocking-b2g:2.0+; status-b2g-v2.0M:affected	Device launch blocker; general issue to overall 2.0 release	Yes	Yes	Yes
blocking-b2g:2.0+; status-b2g-v2.0M:affected	Bug affected 2.0M and it's general to overall 2.0 release	Yes	Yes	Yes
linked to Woodduck_Blocker meta bug; blocking-b2g:2.0M+	Device launch blocker	Yes	---	Yes
blocking-b2g:2.0M+	Bug found or nice to have feature request to 2.0M device launch	Yes	---	Yes
linked to Woodduck_Blocker meta bug; "[2.0M_Only]" in the whiteboard; blocking-b2g:2.0M+	Device launch blocker, but specific to this platform	---	---	Yes
"[2.0M_Only]" in the whiteboard; blocking-b2g:2.0M+	Bug found or nice to have feature request to 2.0M device launch only	---	---	Yes

Landing target

• In short, we have 3 major difference places to land fixes:
  • Master / mozilla-central
  • FxOS release branch
  • FxOS platform branch
• So, based on what we are tagging on bugs, the relationship between landing target and bug tagging:

	Platform launches(2.0M+)	Platform affected(2.0M+, 2.0M affected)	Platform only(2.0M Only)
Master / m-c	Yes	Yes	No
FxOS release branch(2.0)	No	Yes	No
FxOS platform branch(2.0M)	Yes	Yes	Yes

Release Triage

• Dial-in and Vidyo connection details for all triage sessions are the same as all Firefox OS general meetings: https://wiki.mozilla.org/B2G#Meetings

Triage for 2.1.0

Schedule

• Starting September 1st, Every Tuesday at 10 am PT in B2G vidyo room
• Every Wednesday and Thursday at 8:30 am PT in B2G vidyo room

Queries

• 2.1?: http://mzl.la/1ATgdGM
• 2.1+: http://mzl.la/1l1nmh4
• 2.1 Smoke test bugs: http://mzl.la/1rFBlR9
• 2.1 regression bugs: http://mzl.la/1rPKF4I
• 2.1 Crash bugs: http://mzl.la/1l1nM6U
• Unassigned 2.1+ bugs: http://mzl.la/1onQuE1
• 2.1+ blockers last commented since 3 days: http://mzl.la/1nCPHyr

Triage for 2.0.0

Schedule

• Starting June 10th, Every Tuesday at 10 am PT in B2G vidyo room
• Every Wednesday and Thursday at 8:30 am PT in B2G vidyo room

Queries

• 2.0?: http://mzl.la/1l1oJfB
• 2.0+: http://mzl.la/1nCN3sg
• 2.0 Smoke test bugs: http://mzl.la/1pkM8dk
• 2.0 Crash bugs: http://mzl.la/1tKCC7a
• Unassigned 2.0+ bugs: http://mzl.la/1mNoKmW
• 2.1+ blockers last commented since 3 days: http://mzl.la/1pTyHT6

Triage for 1.4.0

Schedule

• Three sessions: Tues/Weds/Thurs at 08:30 AM PST / 16:30 CET / 23:30 CST (US + EU)
• One session: Weds (US) + Thurs (EU/TW) at 22:00 PST / 06:00 CET / 13:00 CST

Queries

• 1.4?
• 1.4+
• 1.4 Smoke test bugs
• 1.4 Crash bugs
• Unassigned 1.4+ bugs
• 1.4+ blockers last commented since 3 days

Triage for 1.3.0

Schedule

• Three sessions: Weds/Thurs at 08:30 AM PST / 16:30 CET / 23:30 CST (US + EU)
• Tuesday triage: 10AM PST
• One session: Weds (US) + Thurs (EU/TW) at 22:00 PST / 06:00 CET / 13:00 CST

Queries

• 1.3?
• 1.3+
• Smoke test bugs
• Crash bugs
• Unassigned 1.3+ blockers
• Unassigned 1.3? bugs
• 1.3+ blockers last commented since 3 days

Tarako Triage

• Everyday 4pm Asia (Taipei) / 9am CET
• [US coverage] Wednesday 2-3 PM PT in B2G vidyo room and Thursday 9:30 - 10:00 am PT in Bhavana's vidyo room
• Bug queries
  • Partner test blockers, whiteboard [SI-testing-blocker]: http://goo.gl/Xt1Z6B
  • 1.3T+ Nobody's : http://goo.gl/SCGhvc
  • Unresolved 1.3T+: http://mzl.la/1hVbw6O (does not include POVB blocking bugs)
  • Full unresolved 1.3T+ last commented since 3 days: http://goo.gl/bCose2
  • 1.3T?: http://goo.gl/axBcEC
  • 1.3T+: http://goo.gl/XY5wSt
  • 1.3T+ with [demo] whiteboard: http://goo.gl/oDgz3Y
  • 1.3T+ bugs with [tarako_only] whiteboard: http://goo.gl/1G3GsX
  • 1.3T+ bugs with [POVB] whiteboard: http://goo.gl/tKXE0H
  • Bugs uplifted to Tarako branch (status-b2g-v1.3T: fixed): http://goo.gl/F6kXAg
  • Bugs pending uplifts to Tarako branch (status-b2g-v1.3T: not fixed): http://mzl.la/1qokks8
  • Resolved 1.3T+: http://goo.gl/Fx599A

Blocker Triage Guidelines

Issues that Should Block

• Major issue in new feature - especially those in which a large number of users will be impacted, or a smaller number of users will be significantly impacted
• Major identifiable regressions (perf or otherwise)
• Non-localizable strings
• Top Crashes
• sec-high, sec-critical security bugs
• Smoke-test regression
• Data loss
• Issues that block partner certification (bluetooth, wifi, legal, etc.)
• Issues getting a lot of support calls with partners or on SUMO
• Issues critical around updates (especially if there's been a repro)
• Anything critical around the first time experience
• Major Dialer, SMS, and VM communication issues
• Issues that prevent automated tests in established testsuites (visible test suites on b2g integration branches on TBPL) from running green at least 90% of the time.
• Certification waivers from the previous release (new policy)
• Major issue with an embedded 3rd party app (in case it can't be solved, it could be decided to remove the app)

Issues that Should Not Block

Any exceptions to these rules must be discussed on b2g-release-drivers@mozilla.org or with Release Management:

• Enhancements
• New Features
• New perf requirements (see enhancements)
• Non-critical string changes (due to l10n)
• Polish and other minor issues
• Unfinished localization (except in the last ~3 weeks of the release)
• Issues requiring the user to perform extremely uncommon use cases
• Issues in languages not being shipped in the version of B2G
• Bugs without clear STR or that are not reproducible
• Bugs that do not impact production phones or the simulator

Blocker Nomination Notes

Here are some other pointers to keep in mind:

• Please do not file a bug without having first determined whether or not it's a regression. If you find it is a regression, please add the keyword and help identify a regression window
• Please ensure that anybody who is nominating critical issues is aware of the above criteria
• Please include a description of why an issue is critical for you when nominating (tell us if it's a certification blocker)
• Do not file multiple issues in a single bug
• Please make sure that whoever nominates a bug for blocking is available to promptly answer questions. Even better, please make sure to use one Bugzilla account per individual nominating.

Whiteboards & Flags

Blocker Whiteboard Additions

As of the week of 4/15/13, we will now use:

• [POVB] in the whiteboard to denote "part of vendor build" (OEM-specific)
  • Denotes that this bug is the responsibility of the OEM
  • Used in conjunction with an impacted device in the whiteboard, for instance [buri], [ikura], or [COM_RIL] (for partner RIL issues)
• [NPOTB] in the whiteboard to denote "not part of the build"
  • Used for bugs that involve server infrastructure, build scripts, tests, etc.
• [Apps Watch List] is the whiteboard used for any bug that impacts apps sourced from Marketplace, the Review process, or bugs used to generate grid builds. The resolution of these bugs have been determined to be outside the sphere of control of the 3rd party developer who is responsible for submissions to the Marketplace. App Review Team, Partner Engineering and Content Program Management use the flag to track bugs that impact their arena.
• [Apps Watch List1] is used for bugs related to pre-installed apps that are the responsibility of a 3rd party developer to resolve. The Apps Review team uses this tag to trigger communications to the 3rd party developers who contribute apps to Marketplace.

Flag Descriptions

• blocking-basecamp is no longer in use (https://bugzilla.mozilla.org/show_bug.cgi?id=830433)
• blocking-b2g
  • blocking-b2g:tef? is for nominating CRITICAL bug fixes to be considered for v1.0.0.0 after 1/15/2013
  • blocking-b2g:tef+ is for bugs that we've got agreement with partners about needing as part of v1.0.0.0
  • blocking-b2g:shira? is for nominating bug fixes to be considered for v1.0.1
  • blocking-b2g:shira+ is for bugs required for v1.0.1 to ship
  • blocking-b2g:leo? is for nominating bug fixes to be considered for v1.1.0
  • blocking-b2g:leo+ is for bugs required for v1.1.0 to ship
• tracking-b2g18:+ means the bug must be fixed on the v1 branch, and tracking-b2g18:? represents a nomination
• tracking-b2g18:19+ means the bug must be fixed on the v1 branch within 6 weeks after v1.0 code ships (to be fixed prior to FF19's release). This flag will be used for security bugs fixed in FF19, for example.
• status-b2g18-v1.0.0 represents the fix status on v1.0.0 branch (gaia v1.0.0 and/or mozilla-b2g18_v_1_0_0)
• status-b2g18 represents the fix status on the v1.* branches (currently v1.0.1 until it branches, we'll add a separate status flag for it)