1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
# 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.
## Responsibilities
### Required, in rough order of priority:
* Identify new network bugs on the tracker.
* Investigate UMA notifications.
* 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&sort=-id&num=1000).
* All Unconfirmed issues filed during your triage rotation should be scanned,
and, 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://sites.google.com/a/chromium.org/dev/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 UMA notifications.
* UMA notifications ("chirps") are alerts based on UMA histograms that are
sent to chrome-network-debugging@google.com. Triagers should subscribe
to this list. When an alert fires, the triager should determine if the
alert looks to be real and file a bug with the appropriate label if so.
Note that if no label more specific than Internals>Network is
appropriate, the responsibility remains with the triager to continue
investigating the bug, as above.
* The triager is responsible for looking at any notification previous
triagers did not, so when an issue is investigated, the person who did
so should respond to chrome-network-debugging@google.com with a short
email, describing their conclusions. Future triagers can then use the
fact an alert was responded to as an indicator of which of them need
to be followed up on. Alerts fired before the beginning of the
previous triager's rotation may be ignored.
* 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.
* Mark it as Needs-Feedback.
* 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 browser process
[crashers](https://goto.google.com/chromecrash) that are potentially network
related. You should look at crashes for the most recent canary that has at
least a day of data, and if there's been a dev or beta release from the start
of the last triager's shift to the start of yours, you should also look at
that once it has at least a day of data. Recent releases available
[here](https://omahaproxy.appspot.com/). If both dev and beta have been
released in that period, just look at beta. File Internals>Network bugs on
the tracker when new crashers are found. Bugs should only be filed for
crashes that are both in the top 100 for each release and occurred for more
than two users.
* Make sure to check for new crashes on all platforms, not just Windows.
* [go/chromenetcrash](https://goto.google.com/chromenetcrash) has a list
of net crashes by version, though makes it more difficult to tell if a
crash makes up a significant portion of all Chrome crashes.
### 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.
See [bug-triage-suggested-workflow.md](bug-triage-suggested-workflow.md) for
suggested workflows.
See [bug-triage-labels.md](bug-triage-labels.md) for labeling tips for network
and non-network bugs.
See [crash-course-in-net-internals.md](crash-course-in-net-internals.md) for
some help on getting started with chrome://net-internals debugging.
|
