Confirmed users
811
edits
B2G/Triage: Difference between revisions
Jump to navigation
Jump to search
→FxOS Device Group
Joshwalker (talk | contribs) |
Joshwalker (talk | contribs) |
||
| Line 35: | Line 35: | ||
* The triage process is handled by FxOS device group. To plus them or not is decided based on the influence on device launches. | * 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: | * Blocking-b2g flag indicates where the fixes should be landed to. And, it depends on: | ||
** If the issue is regression | ** 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. | *** 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. | *** 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. | ||
| Line 42: | Line 42: | ||
*** Otherwise(to 2.1 or 2.2), fixes will go to platform branches "and" master / mozilla-central as well. | *** 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 P1 bug, device group will configure the P1 bug to block a device launch meta bug(for example, Woodduck_P1 meta bug). | * After partner and device group identified a bug as a device P1 bug, device group will configure the P1 bug to block a device launch meta bug(for example, Woodduck_P1 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 | * 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 P1(blocking-b2g:release#+), FxOS core group shouldn't minus it, due to its urgency and importance on device launches. | * Once a bug is tagged as a P1(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): | * So, overall, the tagging rule after triage driven by device group is(take 2.0M as an example): | ||