diff options
Diffstat (limited to 'chromium/net/docs/bug-triage.md')
| -rw-r--r-- | chromium/net/docs/bug-triage.md | 191 |
1 files changed, 86 insertions, 105 deletions
diff --git a/chromium/net/docs/bug-triage.md b/chromium/net/docs/bug-triage.md index 25348795d97..ab02bbe8ff8 100644 --- a/chromium/net/docs/bug-triage.md +++ b/chromium/net/docs/bug-triage.md @@ -1,115 +1,96 @@ # Chrome Network Bug Triage -The Chrome network team uses a two day bug triage rotation. The main goals are -to identify and label new network bugs, and investigate network bugs when no -label seems suitable. +The Chrome network team uses a two day bug triage rotation. The goal is to +review outstanding issues and keep things moving forward. The rotation is time +based rather than objective based. Sheriffs are expected to spend the majority +of their two days working on bug triage/investigation. + +## 1. Review untriaged bugs + +Look through [this list of untriaged +bugs](https://bugs.chromium.org/p/chromium/issues/list?sort=pri%20-stars%20-opened&q=component%3AInternals%3ENetwork%20status%3Aunconfirmed%2Cuntriaged%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3EDNS%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3ECertificate%20-component%3AInternals%3ENetwork%3EReportingAndNEL%20-component%3AInternals%3ENetwork%3EDataUse%20-component%3AInternals%3ENetwork%3EEV%20-component%3AInternals%3ENetwork%3EDataProxy%20-component%3AInternals%3ENetwork%3ECertTrans%20-component%3AInternals%3ENetwork%3ENetworkQuality%20-component%3AInternals%3ENetwork%3EDoH%20-component%3AInternals%3ENetwork%3ENetInfo%20-component%3AInternals%3ENetwork%3EVPN%20-Needs%3DFeedback). + +* Go through them in the given order (top to bottom). + The link sorts them by priority and then recency. +* The goal is to move them out of the untriaged bug queue and give them a priority. + +For each bug try to: + +* Remove the `Internals>Network` component if it belongs elsewhere +* Dupe it against an existing bug +* Close it `WontFix` if appropriate +* Give the bug a priority. Refer to [this (internal) document for guidelines](https://goto.google.com/xnzwn) +* If the bug is a potential security issue (Allows for code execution from remote + site, allows crossing security boundaries, unchecked array bounds, etc) mark + it `Type-Bug-Security`. +* If the bug has privacy implications mark it with component `Privacy`. +* Mark it as a feature request or task if appropriate +* Ask the reporter to narrow down regressions, possibly by using + [bisect-builds-py](https://www.chromium.org/developers/bisect-builds-py). To + view suspicious changelists in a regression window, you can use the Change Log + form on [OmahaProxy](https://omahaproxy.appspot.com/) +* CC others who may be able to help +* Mark it as `Needs-Feedback` and request more information if needed. +* Request a NetLog that captures the problem. You can paste this on the bug: + ``` + Please collect and attach a chrome://net-export log. + Instructions can be found here: + https://chromium.org/for-testers/providing-network-details + ``` +* If a NetLog was provided, try to spend a bit of time reviewing it. See + [crash-course-in-net-internals.md](crash-course-in-net-internals.md) for an + introduction. +* Move to a subcomponent of `Internals>Network` if appropriate. See + [bug-triage-labels.md](bug-triage-labels.md) for an overview of the components. +* If the bug is a crash, see [internal: Dealing with a crash + ID](https://goto.google.com/network_triage_internal#dealing-with-a-crash-id) +and [internal: Investigating +crashers](https://goto.google.com/network_triage_internal#investigating-crashers) + +## 2. Follow-up on issues with the Needs-Feedback label + +Look through [this list of Needs=Feedback +bugs](https://bugs.chromium.org/p/chromium/issues/list?sort=pri%20-modified&q=component%3AInternals%3ENetwork%20Needs%3DFeedback%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3EDNS%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3ECertificate%20-component%3AInternals%3ENetwork%3EReportingAndNEL%20-component%3AInternals%3ENetwork%3EDataUse%20-component%3AInternals%3ENetwork%3EEV%20-component%3AInternals%3ENetwork%3EDataProxy%20-component%3AInternals%3ENetwork%3ECertTrans%20-component%3AInternals%3ENetwork%3ENetworkQuality%20-component%3AInternals%3ENetwork%3EDoH%20-component%3AInternals%3ENetwork%3ENetInfo%20-component%3AInternals%3ENetwork%3EVPN). + +* Go through them in the given order (top to bottom). + The link sorts them by priority and then recency. +* If the requested feedback was provided, review the new information and repeat + the same steps as (1) to re-triage based on the new information. +* If the bug had the `Needs-Feedback` label for over a week and the + feedback needed to make progress was not yet provided, archive the bug. + +## 3. (Optional) Look through crash reports + +Top crashes will already be entered into the bug system by a different process, +so will be handled by the triage steps above. + +However if you have time to look through lower threshold crashes, see +[internal: Looking for new crashers](https://goto.google.com/network_triage_internal#looking-for-new-crashers) + +## 4. Send out a sheriff report + +On the final day of your rotation, send a brief summary to net-dev@chromium.org +detailing any interesting or concerning trends. Do not discuss any restricted +bugs on the public mailing list. ## Management -Owners for the network bug triage rotation can find instructions on -generating and modifying shifts -[here (internal-only)](https://goto.google.com/pflvb). - -## Responsibilities - -### Required, in rough order of priority: -* Identify new network bugs on the tracker. -* Investigate recent `Internals>Network` issues with no subcomponent. -* Follow up on `Needs-Feedback` issues for all network components. -* Identify and file bugs for significant new crashers. - -### Best effort, also in rough priority order: -* Investigate unowned and owned-but-forgotten net/ crashers. -* Investigate old bugs. -* Close obsolete bugs. - -All of the above is to be done on each rotation. These responsibilities should -be tracked, and anything left undone at the end of a rotation should be handed -off to the next triager. The downside to passing along bug investigations like -this is each new triager has to get back up to speed on bugs the previous -triager was investigating. The upside is that triagers don't get stuck -investigating issues after their time after their rotation, and it results in a -uniform, predictable two day commitment for all triagers. - -## Details - -### Required: - -* Identify new network bugs on the bug tracker, looking at [this issue tracker - query](https://bugs.chromium.org/p/chromium/issues/list?q=status%3Aunconfirmed+-commentby=425761728072-pa1bs18esuhp2cp2qfa1u9vb6p1v6kfu@developer.gserviceaccount.com&sort=-id&num=1000). - - * All Unconfirmed issues filed during your triage rotation should be scanned - for suspected network bugs, a network component assigned and a - chrome://net-export/ log requested. Suggested text: "Please collect and - attach a chrome://net-export log. Instructions can be found here: - https://chromium.org/for-testers/providing-network-details". - A link to the instructions appears on net-export, for easy reference. - When asking for a log or more details, attach the Needs-Feedback label. - - * A triager is responsible for looking at bugs reported from noon PST / - 3:00 pm EST of the last day of the previous triager's rotation until the - same time on the last day of their rotation. - -* Investigate [Unconfirmed / Untriaged Internals>Network issues that don't belong to a more specific network component](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3DInternals%3ENetwork+status%3AUnconfirmed,Untriaged+-label:Needs-Feedback&sort=-modified), - prioritizing the most recent issues, ones with the most responsive reporters, - and major crashers. This will generally take up the majority of your time as - triager. Continue digging until you can do one of the following: - - * Mark it as `WontFix` (working as intended, obsolete issue) or a - duplicate. - - * Mark it as a feature request. +* Your rotation will appear in Google Calendar as two days. You are expected to + work on it full-time (as best you can) during those calendar days, during your + ordinary working hours. - * Mark it as `Needs-Feedback`. +* Google Calendar [google.com_52n2p39ad82hah9v7j26vek830@group.calendar.google.com](https://calendar.google.com/calendar/embed?src=google.com_52n2p39ad82hah9v7j26vek830%40group.calendar.google.com&ctz=America%2FLos_Angeles) - * Remove the `Internals>Network` component, replacing it with at least one - more specific network component or non-network component. Replacing the - `Internals>Network` component gets it off the next triager's radar, and - in front of someone more familiar with the relevant code. Note that - due to the way the bug report wizard works, a lot of bugs incorrectly end - up with the network component. - - * The issue is assigned to an appropriate owner. Make sure to mark it as - "assigned" so the next triager doesn't run into it. - - * If there is no more specific component for a bug, it should be - investigated by the triager until we have a good understanding of the - cause of the problem, and some idea how it should be fixed, at which point - its status should be set to Available. Future triagers should ignore bugs - with this status, unless investigating stale bugs. - -* Follow up on [Needs-Feedback issues for all components owned by the network stack team](https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork+-component%3AInternals%3ENetwork%3EDataProxy+-component%3AInternals%3ENetwork%3EDataUse+-component%3AInternals%3ENetwork%3EVPN+Needs%3DFeedback&sort=-modified). - - * Remove label once feedback is provided. Continue to investigate, if - the previous section applies. - - * If the `Needs-Feedback` label has been present for one week, ping the - reporter. - - * Archive after two weeks with no feedback, telling users to file a new - bug if they still have the issue, with the requested information, unless - the reporter indicates they'll provide data when they can. In that case, - use your own judgment for further pings or archiving. - -* Identify significant new crashes. See [internal documentation](https://goto.google.com/network_triage_internal#looking-for-new-crashers). - -### Best Effort (As you have time): - -* Investigate old bugs, and bugs associated with `Internals>Network` - subcomponents. - -* Investigate unowned and owned but forgotten net/ crashers that are still - occurring (As indicated by - [go/chromenetcrash](https://goto.google.com/chromenetcrash)), prioritizing - frequent and long standing crashers. - -* Close obsolete bugs. +* Owners for the network bug triage rotation can find instructions on +generating and modifying shifts +[here (internal-only)](https://goto.google.com/pflvb). -See [bug-triage-suggested-workflow.md](bug-triage-suggested-workflow.md) for -suggested workflows. +* An overview of bug trends can be seen on [Chromium + Dashboard](https://chromiumdash.appspot.com/components/Internals/Network?project=Chromium) -See [bug-triage-labels.md](bug-triage-labels.md) for labeling tips for network -and non-network bugs. +* There is also an [internal dashboard with bug trends for Web + Platform](https://goto.google.com/vufyq) that includes network issues. -See [crash-course-in-net-internals.md](crash-course-in-net-internals.md) for -some help on getting started with chrome://net-internals debugging. +* The issue tracker doesn't track any official mappings between components and + OWNERS. This [internal document](https://goto.google.com/kojfj) enumerates + the known owners for subcomponents. |