B2G/Triage: Difference between revisions

From MozillaWiki
< B2G
Jump to navigation Jump to search
(→‎1.0.0 (TEF): fixed order-by, yet again)
(Obsolete content)
 
(174 intermediate revisions by 18 users not shown)
Line 1: Line 1:
{{RELEASE_MANAGEMENT_OBSOLETE}}
This page is a rollup of all the bug queries floating across the B2G project.  This will include Gonk, Gaia, Gecko, and Marketplace.   
This page is a rollup of all the bug queries floating across the B2G project.  This will include Gonk, Gaia, Gecko, and Marketplace.   


== Performance Nomination ==
== Branch Rules ==
'''3 times a week meetings'''
* Development Branch
* Monday, Wednesday, Friday: 9 am (PST), 18:00 (CET)
** master / [[Tree Rules|mozilla-central]]
** [[Tree Rules|mozilla-aurora]]
* Release Branch
* Platform Branch


'''Connection Information'''
* Original Diagram: https://docs.google.com/a/mozilla.com/drawings/d/1boCUd95zY090mNhuu6A4LO8XJnshKi6pisj18wc2Gr0/edit?usp=sharing
* Vidyo connection details:
[[File:Branch model.png]]
** Room: David Scravaglieri (9807)
** Guest Access (Need Vidyo Desktop and a Browser): http://bit.ly/14oKDCm
** By Phone: +1 800 707 2533, pin 369 - then 99807#


'''Search'''
== Triage and Landing Responsibility ==
* The Bugzilla Searches requests are:
** [FFOS_perf] Nominations: http://bit.ly/Vx4GOJ
** [FFOS_perf] Status: http://bit.ly/WETpuv


'''Performance'''
=== FxOS Core Group ===
* Performance Graphic: https://datazilla.mozilla.org/b2g/
* 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.


== Triage Schedule ==
==== 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


'''Connection Information'''
=== 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, [https://bugzilla.mozilla.org/show_bug.cgi?id=1080337 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):
{| class="wikitable"
! 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:
{| class="wikitable"
|-
!  !! 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
|}
 
[[File:Landing Target.png]]
 
== 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
* 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


===1.0.0 (TEF)===
===Triage for 2.5.0 ===
'''Schedule'''
* FxOS event Public calendar link : http://bit.ly/1rdBtYW


'''Queries'''
* 2.5?: http://mzl.la/1T9xI0E
* 2.5+: http://mzl.la/1T9y2N0
* 2.5 Smoke test bugs: http://mzl.la/1T9ydaW
* 2.5 regression bugs: http://mzl.la/1T9xI0E
* 2.5 Crash bugs: http://mzl.la/1T9yBpR
* Unassigned 2.5+ bugs: http://mzl.la/1LLVxu8
* 2.5+ blockers last commented since 3 days: http://mzl.la/1LLVVZQ
===Triage for 2.2.0 ===
'''Schedule'''
'''Schedule'''
* US/EU - Mondays - Friday at 08:00 Pacific (17:00 CET)
<s>
* 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
</s>
'''Queries'''
* 2.2?: http://mzl.la/14swFUO
* 2.2+: http://mzl.la/14sx89F
* 2.2 Smoke test bugs: http://mzl.la/1KJ5FC8
* 2.2 regression bugs: http://mzl.la/1rPKF4I
* 2.2 Crash bugs: http://mzl.la/1l1nM6U
* Unassigned 2.2+ bugs: http://mzl.la/1onQuE1
* 2.2+ blockers last commented since 3 days: http://mzl.la/1nCPHyr


* Platform triage: M,W,Th,F: 10-11am PST, Tu: 10:30-11am PST
===Triage for 2.1.0 ===
'''Schedule'''
<s>
* 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
</s>
'''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


'''Searches'''
===Triage for 2.0.0 ===
* blocking-b2g - partner required changes/fixes
'''Schedule'''
** [http://mzl.la/tefnoms tef?]
<s>
** [http://bit.ly/Yb2FCl unfixed tef+]
* Starting June 10th, Every Tuesday at 10 am PT in B2G vidyo room
** [http://mzl.la/TZaG2i  fixed, not on v1.0.0 branch]
* Every Wednesday and Thursday at 8:30 am PT in B2G vidyo room
</s>
'''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.0+ blockers last commented since 3 days: http://mzl.la/1pTyHT6


===1.0.1 (Shira)===
===Triage for 1.4.0 ===
'''Schedule'''
<s>
* 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
</s>
'''Queries'''
* [http://mzl.la/1lqEZf0 1.4?]
* [http://mzl.la/1fG55DY 1.4+]
* [http://mzl.la/1fG5shL 1.4 Smoke test bugs]
* [http://mzl.la/MnnGeT 1.4 Crash bugs]
* [http://mzl.la/1nCBSSd Unassigned 1.4+ bugs]
* [http://mzl.la/1dTmGFh 1.4+ blockers last commented since 3 days]


===Triage for 1.3.0 ===
'''Schedule'''
'''Schedule'''
* 17:00CST every Tuesdays and Thursdays (EU 10:00 CET, US 01:00 PST)
<s>
* If you want to join, please contact khu and we can setup a line to join. We don't use any line. We just met & triage in a meeting room in Taipei office.
* 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
</s>
'''Queries'''
* [http://mzl.la/19i66li 1.3?]
* [http://mzl.la/1cBIKrj 1.3+]
* [http://mzl.la/1d8rSXk Smoke test bugs]
* [http://mzl.la/18CuiLp Crash bugs]
* [http://mzl.la/1gNrAWv Unassigned 1.3+ blockers]
* [http://mzl.la/1bELfJw Unassigned 1.3? bugs]
* [http://mzl.la/1aW6lyD 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 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:


'''Searches'''
* Enhancements
* [https://bugzilla.mozilla.org/buglist.cgi?field0-0-0=cf_blocking_b2g;query_format=advanced;type0-0-0=equals;value0-0-0=shira%3F shira?]
* New Features
* [https://bugzilla.mozilla.org/buglist.cgi?value0-1-0=fixed%20verified%20unaffected%20wontfix;value0-0-0=shira%2B;type0-1-0=nowordssubstr;type0-0-0=equals;query_format=advanced;field0-0-0=cf_blocking_b2g;field0-1-0=cf_status_b2g18 unfixed shira+]
* 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


'''Connection Information (From February 12 - 15)'''
=== Blocker Nomination Notes ===
* Vidyo connection details:
Here are some other pointers to keep in mind:
** Room: David Scravaglieri (9807)
** Guest Access (Need Vidyo Desktop and a Browser): http://bit.ly/14oKDCm
** By Phone: +1 800 707 2533, pin 369 - then 99807#


===1.1.0 (Leo)===
* 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.


'''Schedule'''
== Whiteboards & Flags ==
* US/TW Mondays at 16:00 PST (08:00 CST)
 
* US/EU Thursdays at 09:00 PST (18:00 CET)
=== Blocker Whiteboard Additions ===
As of the week of 4/15/13, we will now use:


'''Searches'''
* '''[POVB]''' in the whiteboard to denote "part of vendor build" (OEM-specific)
* [https://bugzilla.mozilla.org/buglist.cgi?field0-0-0=cf_blocking_b2g;query_format=advanced;type0-0-0=equals;value0-0-0=leo%3F leo?]
** Denotes that this bug is the responsibility of the OEM
* [https://bugzilla.mozilla.org/buglist.cgi?type0-1-0=nowordssubstr;field0-1-0=cf_status_b2g18;field0-0-0=cf_blocking_b2g;query_format=advanced;value0-1-0=fixed%20verified%20unaffected%20wontfix;type0-0-0=equals;value0-0-0=leo%2B unfixed leo+]
** 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===
===Flag Descriptions===
* '''blocking-basecamp''' is no longer in use (https://bugzilla.mozilla.org/show_bug.cgi?id=830433)
* '''blocking-basecamp''' is no longer in use (https://bugzilla.mozilla.org/show_bug.cgi?id=830433)
* '''blocking-b2g'''
* '''blocking-b2g'''
Line 78: Line 293:
* '''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)
* '''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)


=== More v1.x Triage Queries ===
== 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)


* tracking-b2g18 - v1.x fixes (functional, security, or otherwise)
'''Note'''
** [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced;order=Bug%20Number;field0-0-0=cf_tracking_b2g18;type0-0-0=equals;value0-0-0=%3F tracking nominations]
* Triage guideline https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines
** [https://bugzilla.mozilla.org/buglist.cgi?type0-1-0=nowordssubstr;order=Bug%20Number;field0-1-0=cf_status_b2g18;field0-0-0=cf_tracking_b2g18;query_format=advanced;value0-1-0=fixed%20verified%20unaffected%20wontfix;type0-0-0=equals;order=Bug%20Number;value0-0-0=%2B tracked and unfixed, but not for a specific version]
** [https://bugzilla.mozilla.org/buglist.cgi?type0-1-0=nowordssubstr;order=Bug%20Number;field0-1-0=cf_status_b2g18;field0-0-0=cf_tracking_b2g18;query_format=advanced;value0-1-0=fixed%20verified%20unaffected%20wontfix;type0-0-0=equals;order=Bug%20Number;value0-0-0={{BETA_VERSION}}%2B tracked and unfixed, to be fixed before release of Firefox {{BETA_VERSION}}]
* [https://bugzilla.mozilla.org/buglist.cgi?field0-0-0=flagtypes.name;order=Bug%20Number;query_format=advanced;type0-0-0=substring;value0-0-0=approval-mozilla-b2g18%3F approval-b2g18:?]
* [https://bugzilla.mozilla.org/buglist.cgi?list_id=5454927;field0-0-0=flagtypes.name;order=Bug%20Number;type0-0-0=substring;value0-0-0=approval-gaia-v1%3F;query_format=advanced approval-gaia-v1:?]


== [OLD] Gecko, WebAPIs, B2G ==
===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


=== Searches used during triage ===
===tracking-b2g Flag===
* "platform" '''noms''' (not blocked on input):  http://bit.ly/X82cWA
'''Definition'''
* "platform" noms in '''NEEDINFO''' state:  http://bit.ly/WyB1zf
* The teams need such a bucket to track backlog items apart from blocking-b2g and feature-b2g.  
* '''ownerless''' "platform" blockers (basecamp+):  http://bit.ly/XT6GQU
* Attributes, sorted in priority
* '''unprioritized''' "platform" blockers sorted by last touched: http://bit.ly/V7utHb (note: you may have to add the "Changed" column with "Change Columns" at the bottom)
** tracking-b2g:+ is the TopX item in the backlog
* '''all''' "platform" blockers sorted by last touched:  http://bit.ly/SyXdcR (note: you may have to add the "Changed" column with "Change Columns" at the bottom)
** tracking-b2g:backlog is the regular backlog item
* blockers with '''non-obsolete r+''' patches: http://bit.ly/VuWTv2
** tracking-b2g:--- (default flag. indicating undefined)
* '''Soft''' "platform" blockers:  http://bit.ly/107Q0aX
** tracking-b2g:- (lowest priority)
* Bugs requiring '''b2g18 approval''': http://bit.ly/WswjlG
* Blockers with '''checkin-needed''' keyword:  http://bit.ly/UvxO2V
* '''tef?''':  http://bit.ly/Y5M3lI
* non-Gaia '''tef'''+: http://bit.ly/W45xSJ


==== By Milestone ====
'''Note'''
* <strike>'''C1''' "platform" blockers:  http://bit.ly/QuXxLu</strike>
* 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.
* <strike>'''C2''' "platform" blockers:  http://bit.ly/V6y5sl</strike>
* We don't specify version# because supposedly these are neither release blockers nor feature blockers.
* <strike>'''C3''' "platform" blockers:  http://bit.ly/UDuJ0J</strike>
* '''C4''' "platform" blockers:  http://bit.ly/VkKIC2
* '''un-milestoned''' "platform" blockers:  http://bit.ly/U7o2qY


=== Other searches ===
===ux-b2g Flag===
* all basecamp? in Core/Boot2Gecko products:  http://bit.ly/O3j7p9
'''Definition'''
* all basecamp+ in Core/Boot2Gecko products:  http://bit.ly/Y6sgmx
* Marks UX bugs required for a front-end feature (usually OS-wide) to work properly.
* all basecamp? in all products: http://bit.ly/O3miLI
* Distinguishes polish and non-blocking UX bugs from blocking UX bugs.
* all basecamp+ in all products:  http://bit.ly/NkXeSB
* basecamp+ features:  http://bit.ly/U0jfUa
* basecamp+ non-features:  http://bit.ly/P0Vr0L
* All unresolved basecamp+ in Boot2Gecko::Gaia* : http://bit.ly/RmjxVp
* All basecamp? in Boot2Gecko::Gaia* : http://bit.ly/SvASy3


== [OLD] Gaia ==
'''Rationale and History'''
=== Latest Triage Shortcuts ===
* TEF? nominations: http://bit.ly/10tADcZ
* TEF+ (Gaia+platform):  (http://bit.ly/10yDS2H)


=== Older Triage Searches ===
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.  
* Find out BZ accounts for these issues that had assignees on GH: http://bit.ly/QU1zsO
* Smoketest Blockers: http://bit.ly/W49ivO
* Basecamp nominations: http://bit.ly/U0kdSY
* All open, sorted by recency: http://bit.ly/SjiOJf
* QA blocked (should probably be switched to a keyword): http://bit.ly/PTl3Pu
* P1: http://bit.ly/SjjjDc
* P2: http://bit.ly/QJ3BPw
* Blocked on platform (make sure they're blocked on a Gecko bug, move to a keyword ?): http://bit.ly/OAu7vM
* Needs UX input: https://github.com/mozilla-b2g/gaia/issues?labels=needsUXinput&page=1&state=open
* Needs UX review: list was empty - switch to uiwanted keyword?
* Needs visuals input (keyword?): http://bit.ly/SVOrbv
* Import SIM contacts doesn't complete - https://github.com/mozilla-b2g/gaia/issues/3196
* Gaia blockers assigned to nobody - http://bit.ly/O1ImIl
* Gaia soft blockers - http://bit.ly/13aEb2j


== [OLD] Payments ==
'''Note'''
* Marketplace: https://bugzilla.mozilla.org/showdependencytree.cgi?id=775802&hide_resolved=1
* Gaia: https://github.com/mozilla-b2g/gaia/issues?labels=payments&page=1&state=open


== [OLD] Identity Bugs ==
Only members of the Firefox OS UX team and Release Management should set the ux-b2g flag.
* Identity: https://bugzilla.mozilla.org/showdependencytree.cgi?id=794552&hide_resolved=1
* Gaia / Trusted UI: https://github.com/mozilla-b2g/gaia/issues?labels=system%2Ftrusted_dialog&page=1&state=open


== QA Queries ==
===Keywords and Flags used by QAs===
* B2G and Gaia, All qawanted bugs: http://bit.ly/b2g-gaia-qawanted-all
[[B2G/QA/Triage#Summary_of_Keywords_and_Flags|This Wiki page]] provides a summary of how we manage requests for QA support through Bugzilla, more specifically for the B2G QA team.
* Gecko/core bugs, blocking-basecamp+, resolved fixed: http://bit.ly/b2g-fixed-blockingplus
* All open Gaia bugs: http://bit.ly/VmalWn
* All Gaia Resolved-Fixed bugs: http://bit.ly/blocking-gaiaPlus
* creating a bug: https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko&component=Gaia

Latest revision as of 10:08, 31 January 2018

⚡ 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://dev.wikimo.nonprod.webservices.mozgcp.net/index.php?title=B2G/Triage&oldid=1188262"