mirror/naiveproxy
1
0
Fork 0
mirror of https://github.com/klzgrad/naiveproxy.git synced 2024-12-01 17:56:10 +03:00
Code Issues Projects Releases Wiki Activity
1f0224f0e4
naiveproxy/src/net/docs/bug-triage.md
klzgrad c4a0edfca5 Import chromium-90.0.4430.85
2021-05-21 00:50:53 +08:00

8.7 KiB
Raw Blame History

Chrome Network Bug Triage

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.

The goal is for this query to be empty. Bugs can be removed from the triage queue by doing any of the following:

  • Changing the bug status - marking the bug Available, or closing it.
  • Removing the Internals>Network component or subcomponent.
  • Adding the label Network-Triaged (when there are multiple components).

For each bug try to:

  • Remove the Internals>Network component or subcomponent if it belongs elsewhere
  • Dupe it against an existing bug
  • Close it as WontFix.
  • Give the bug a priority. Refer to this document for guidelines
  • 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.
  • Set the type to Task or Feature when it is not a bug.
  • Pay extra attention to possible regressions. Ask the reporter to narrow down using bisect-builds-py. To view suspicious changelists in a regression window, you can use the Change Log form on OmahaProxy
  • CC others who may be able to help
  • Mark it as Needs-Feedback and request more information if needed.
  • In cases where the bug has multiple components, but primary ownership falls outside of networking, further network triage may not be possible. In those cases, if possible remove the networking component. Otherwise, add the Network-Triaged label to the bug, and add a comment explaining which team should triage further. Adding the Network-Triaged serves to filter the bug from our untriaged bug list.
  • Avoid spending time deep-diving into ambiguous issues when you suspect it is an out of scope server or network problem, and is not clearly high priority (for instance, it affects only 1 user and is not a regression). Instead:
    • Mark the bug as Available with Priority 3.
    • Add the Needs-Feedback label
    • Add a comment thanking the reporter, but explaining the issue is ambiguous and they need to do the debugging to demonstrate it is an actual Chrome bug.
      • Point them to chrome://net-export and the NetLog Viewer.
      • Ask them to confirm whether it is a Chromium regression. (Regressions are treated as high priority)
  • 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 for an introduction.
  • Move to a subcomponent of Internals>Network if appropriate. See bug-triage-labels.md for an overview of the components.
  • If the bug is a crash, see internal: Dealing with a crash ID and internal: Investigating crashers

2. Follow-up on issues with the Needs-Feedback label

Look through this list of Needs=Feedback bugs.

  • 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 30 days, and the feedback needed to make progress was not yet provided, archive the bug.

3. Ensure P0 and P1 bugs have an owner

Look through the list of unowned high priority bugs. These bugs should either have an owner, or be downgraded to a lower priority.

4. (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

5. 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.

Covered bug components

Not all of the subcomponents of Interals>Network are handled by this rotation.

The ones that are included are:

Internals>Network
Internals>Network>Auth
Internals>Network>Cache
Internals>Network>Connectivity
Internals>Network>DomainSecurityPolicy
Internals>Network>Filters
Internals>Network>FTP
Internals>Network>HTTP2
Internals>Network>Library
Internals>Network>Logging
Internals>Network>Proxy
Internals>Network>QUIC
Internals>Network>SDCH
Internals>Network>SSL
Internals>Network>TrustTokens

The rest of the Internals>Network subcomponents are out of scope, and covered by separate rotations:

Internals>Network>Certificate
Internals>Network>CertTrans
Internals>Network>Cookies
Internals>Network>DataProxy
Internals>Network>DataUse
Internals>Network>DNS
Internals>Network>DoH
Internals>Network>EV
Internals>Network>NetInfo
Internals>Network>NetworkQuality
Internals>Network>ReportingAndNEL
Internals>Network>VPN

Management