B2G/Triage

From MozillaWiki
< B2G
Jump to: navigation, search

⚡ Warning: The content of this page is obsolete and kept for archiving purposes of past processes.

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

Branch Rules

Branch model.png

Triage and Landing Responsibility

FxOS Core Group

  • The triage process is handled by FxOS core group. To plus (+) them or not is decided based on triage criteria and urgency level.
  • Before feature complete (FC) 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.

Landing Criteria

  • Core Group only land fixes to following branches:
    • Master / mozilla-central
    • mozilla-aurora
    • FxOS Release Branch (before Code Compelete (CC) milestone)
  • Checklist:
    • Code Review by Core Team
    • Core QA team or Outsource QA team verified
    • (*)Landing Approvals for Release Branch

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 depends on:
    • If the issue is regression and can be reproduced on main release(for example, 2.0+, 2.1+, ...).
      • 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.1S+, …). It means, the bugs only affect platform specific launches. We will tag keywords(ex, "[2.0M_Only], [2.1S_Only]") in the whiteboard and fixes only go to 2.0M / 2.1S 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.1S+, …).
      • If the bugs only affect platform specific launches, we will tag keywords(ex, "[2.0M_Only], [2.1S_Only]") in the whiteboard and fixes only go to 2.0M / 2.1S branch.
      • Otherwise(to 2.1 or 2.2), fixes will go to platform branches "and" master / mozilla-central as well.
  • After partner and device group identified a bug as a device Blocker bug, device group will configure the Blocker bug 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.
  • Device branch sheriff will mark status-b2g-v2.0M to "fixed" and also put “verifyme” at Keywords field if bug assignee initial pull request and review+.
  • Device QA will mark status-b2g-v2.0M to "verified" if bug is verified fixed.
  • 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 Action Landing to master/m-c Landing to Release Ex. 2.0 Landing to Platform Ex. 2.0M
Keyword: regression;

blocking-b2g:2.0M+; status-b2g-v2.0:affected; status-b2g-v2.0M:affected

Bug found in device branch and also identified as regression issue for main release NI release manager for making blocking-b2g:2.0+ Yes Yes Yes
blocking-b2g:2.0M+;

status-b2g-v2.0:affected status-b2g-v2.0M:affected

Bug found in device branch but not regression issue for main release Yes --- Yes
Whiteboard: [2.0M_Only];

blocking-b2g:2.0M+; status-b2g-v2.0:unaffected; status-b2g-v2.0:affected;

Bug found in device branch only --- --- Yes

Landing Criteria

  • Device Group could land fixes to following branches
    • FxOS release branch (Code Completed)
    • FxOS platform branch
  • Checklist:
    • Decision depends on affected flags
    • Code Reviews
    • Core/Device/OutSource QA verified and test results
    • Landing approvals by management stakeholders


  • 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 Only Regression issues No
FxOS platform branch (2.0M) Yes Yes Yes

Landing Target.png

Release Triage

Triage for 2.5.0

Schedule

Queries

Triage for 2.2.0

Schedule

  • Every Tuesday at 8 am PT in B2G vidyo room
  • Every Wednesday 11am PT in B2G vidyo room
  • FxOS event Public calendar link : http://bit.ly/1rdBtYW

Queries

Triage for 2.1.0

Schedule

  • Every Tuesday at 8 am PT in B2G vidyo room
  • Every Wednesday 11am PT in B2G vidyo room
  • FxOS event Public calendar link : http://bit.ly/1rdBtYW

Queries

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

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

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

Tarako Triage

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 Treeherder) 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 block device launches(ex, IOT, CS blockers) and agreed with partners.

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)

Project Flags

blocking-b2g Flag

Definition

  • blocking-b2g:version#? is nomination as blocker for the specific version.
  • blocking-b2g:version#+ indicates as release blocker for the specific version. Decisions are made during triage process.
  • blocking-b2g:--- (default flag. indicating undefined)
  • blocking-b2g:- (meaning non-blocking to any release)

Note

feature-b2g Flag

Definition

  • feature-b2g:version#? is defined as "this feature is being proposed for this release"
  • feature-b2g:version#+ is define as "this feature has been committed or done (by the engineering team(s)) for this release"
  • feature-b2g:--- (default flag. indicating undefined)
  • feature-b2g:- (meaning not a committed feature to any release)

Note

  • [meta] bugs features and all dependencies targeted for a particular release should mark feature-b2g flag.
  • The feature-b2g flag should assigned to engineering tasks falling under the user stories AND the user stories themselves.
  • Who has the permission? PM and EPM, engineer managers and partner peers have the access

tracking-b2g Flag

Definition

  • The teams need such a bucket to track backlog items apart from blocking-b2g and feature-b2g.
  • Attributes, sorted in priority
    • tracking-b2g:+ is the TopX item in the backlog
    • tracking-b2g:backlog is the regular backlog item
    • tracking-b2g:--- (default flag. indicating undefined)
    • tracking-b2g:- (lowest priority)

Note

  • Permission? Everyone in the team should be able to set such flag. We're encouraging the backlog grooming to happen frequently and can be presented by using tracking-b2g flag.
  • We don't specify version# because supposedly these are neither release blockers nor feature blockers.

ux-b2g Flag

Definition

  • Marks UX bugs required for a front-end feature (usually OS-wide) to work properly.
  • Distinguishes polish and non-blocking UX bugs from blocking UX bugs.

Rationale and History

The ux-b2g flag was created during the 2.0 release, which was a "UX heavy release:" 2.0 included a lot of UX changes to gestures, animations, the home screen, and so on. This meant that there were numerous OS-wide features -- like the thin, pale blue notifications bar, for example -- that needed to block 2.0+, and that required many UX bugs to be completed (graphics, transitions, animations). Each of these UX bugs needed to block 2.0+ if the finished, front-end feature was to look and behave properly across the OS. The ux-b2g flag was added when these "smaller" bugs were incorrectly marked as "polish," and were actually needed in order for a feature to work.

Note

Only members of the Firefox OS UX team and Release Management should set the ux-b2g flag.

Keywords and Flags used by QAs

This Wiki page provides a summary of how we manage requests for QA support through Bugzilla, more specifically for the B2G QA team.

Retrieved from "https://wiki.mozilla.org/index.php?title=B2G/Triage&oldid=1188262"