The Chromium Projects

Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.
For Developers‎ > ‎Design Documents‎ > ‎Network Stack‎ > ‎

Network bug triage

Contents

  1. 1 Two levels of network bug triage
  2. 2 Front-line network bug triage
    1. 2.1 Rotation schedule
  3. 3 Second-line network bug triage

Two levels of network bug triage

Network bug triage is done at two levels: front line and second line.

The main goal of front-line bug triage is to make sure all network related bugs are properly labeled (labeling bugs for other areas and figuring out the trend would be a bonus). It should be lightweight compared with the second-line bug triage.

In second-line bug triage, we determine priorities and decide if we want to delve into certain bugs and assign owners to get the bottom of them.

Front-line network bug triage

Front-line network bug triage identifies network bugs among new Chromium bugs with no Cr label. Front-line network bug triage should do the following things:
  • Network bugs should be marked with the Cr-Internals-Network labels. You may assign sub-labels (such as Cr-Internals-Network-Auth) but this is not a requirement.
  • Cr-UI-Browser-Downloads
    • Bugs that involve the process of converting a URL into a file on local disk. Most downloads bugs will have the word "download" or "save as" in the description.  Bugs about downloading chrome itself to install it are not download bugs.
  • Cr-UI-Browser-SafeBrowsing
    • Safe browsing bugs. I.e. ones that have to do with the process by which a URL or file is determined to be dangerous based on our databases.  Determination of danger based purely on content-type or file extension belongs in Feature-Downloads, not SafeBrowsing.
  • Cr-Blink-WebSockets
    • WebSocket bugs
  • Cr-Blink-XHR
    • XMLHttpRequest specific bugs
  • Cr-Internals-Network-DataProxy
    • Bugs that mention usage of Chrome's Data Compression Proxy. Typically these bugs will mention sites that fail to load when the "Reduce Data Usage" option is turned on or sites that look different when this option is turned on. 
  • For a bug in the Unconfirmed status, if you can reproduce the bug or the bug report convinced you that the bug is real, change the status to Untriaged. This is important because the second-line network bug triage will only look at Untriaged bugs.
  • You may assign a bug to an owner and change the status to Assigned if you know who should work on it. If you are not sure whom to assign a bug to, simply cc any people who might know more about it. Project managers triage bugs in the Untriaged status every week.
Tips for doing front-line network bug triage:
  1. Read the instructions for triaging bugs in general, especially the section Categorizing bugs.
  2. Resist the temptation to investigate the bugs yourself. Let the bug owners do that.
  3. Identify trends in bugs and present noteworthy bugs or trends in our weekly meetings.
  4. At the end of the week, write down the last bug number you looked at for handover to the next person on the rotation schedule.
Tips for quickly doing bug triage:
  • Go to this link. It will show the 1000 most recent Unconfirmed bugs.
  • Press "h" to bring up a preview of the bug text.
  • Use "j" and "k" to advance through bugs.
  • If a bug looks like it might be network/download/safe-browsing related, middle click [or command-click on OSX] to open in new tab.
  • If a bug mentions a crash report that could be caused by the net code, inspect the crash id on the crash server to determine the area.
  • After making it through the top-level list, start going through all the issues in the other tabs and assign labels appropriately.

Rotation schedule

Each person does front-line network bug triage for one week. People with other bug triage duties are exempt.

Adding the following calendar will allow you to see the schedule: google.com_52n2p39ad82hah9v7j26vek830@group.calendar.google.com

Current rotation:

2014-07-14 to 2014-07-20: Thomas Tuttle (ttuttle)
2014-07-21 to 2014-07-27: Misha Efimov (mef)
2014-07-28 to 2014-08-03: Wan-Teh Chang (wtc)
2014-08-04 to 2014-08-10: Chris Bentzel (cbentzel)
2014-08-11 to 2014-08-17: Matt Menke (mmenke)
2014-08-18 to 2014-08-24: Matt Mueller (mattm)
2014-08-25 to 2014-08-31: Johnny Graettinger (jgraettinger)
2014-09-01 to 2014-09-07: Paul Jensen (pauljensen)
2014-09-08 to 2014-09-14: Siddharth Vijaykrishnan (sidv)
2014-09-15 to 2014-09-21: Ryan Sleevi (rsleevi)
2014-09-22 to 2014-09-28: Ricardo Vargas (rvargas)
2014-09-29 to 2014-10-05: Randy Smith (rdsmith)
2014-10-06 to 2014-10-12: Jim Roskind (jar)
2014-10-13 to 2014-10-19: raman Tenneti (rtenneti)
2014-10-20 to 2014-10-26: Asanka Herath (asanka)
2014-10-27 to 2014-11-02: Jana Iyengar (jri)
2014-11-03 to 2014-11-09: Ryan Hamilton (rch)
2014-11-10 to 2014-11-16: Gavin Peters (gavinp)
2014-11-17 to 2014-11-23: Misha Efimov (mef)
2014-11-24 to 2014-11-30: David Benjamin (davidben)
2014-12-01 to 2014-12-07: Thomas Tuttle (ttuttle)
2014-12-08 to 2014-12-14: Eric Roman (eroman)
2014-12-15 to 2014-12-21: Elly Jones (ellyjones)
2014-12-22 to 2014-12-28: Josh Karlin (jkarlin)

Second-line network bug triage

Second-line network bug triage is done once a week (every Monday morning) by a project manager and a developer using this crbug query.

Subpages (1): Triaging Downloads Bugs
Comments