tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index f670feb2cc201041ee526132224d7bf42636721b..7e9c30afdead8af3362bdfc100d52a16e2782144 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -29141,6 +29141,9 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
     requirements on a per-domain basis. When pinning requirements are violated,
     Chrome attempts to send a report about the incident. This records the net
     error code when sending a pinning violation report fails.
+
+    In M53 and earlier, the recorded error code was a negative integer; in M54
+    and later, the error code is positive.

[Mark P, 2016/07/08 17:50:58]

I don't like this solution.

Here's why: after this change, the net errors with positive values will be
displayed as human-readable strings in the dashboard. To a quick glance, this
makes the negative values look like bugs / coding errors, not regular /
intended-to-be-reported errors.  If a user wants to answer a question such as
what percent of errors are timeouts, the easiest way is to look at the percent
by the TIMED_OUT line, ignoring the unlabeled values.  But, with this solution,
to do it correctly one would have to notice the warning message / not ignore
out-of-hand the negative values, remember or look up the net error code for
TIMED_OUT, find that negative value, add it to the positive row labeled
TIMED_OUT and then calculate the percent.  You expect a lot from people.

Furthermore, if you use something like the timeline view to graph errors over
time, it doesn't support this type of bucket adding.  And it does sound like
you're wanting to look at data over time: "I'm imagining trying to decide if
there were more ERR_CONNECTION_REFUSED errors this month than last month."

I'd prefer either of these two strategies:
- rename the bad histograms, marking the old ones was obsolete
- add to the histograms.xml NetErrorCodes enum all neterrors as negative values
as well as positive.  You're not likely to be the last person to make this
mistake, and this will prevent needing these corrections in the future.  This
will require updating
  tools/metrics/histograms/update_net_error_codes.py
  and probably also necessitate some discussion with another member of the UMA
team to make strategy is sound.

estark@ wrote: "I'm pretty sure I'm the only one looking at these"
which may be true now, but may change in the future, and users do get stuck on
old versions indefinitely so these negative values will not go away entirely.

   </summary>
 </histogram>
 
@@ -54513,6 +54516,14 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
   </summary>
 </histogram>
 
+<histogram name="SSL.CertificateErrorReportFailure" enum="NetErrorCodes">
+  <owner>estark@chromium.org</owner>
+  <summary>
+    Users can opt in to send reports of certificate validation errors to Google.
+    This records the error code whenever Chrome fails to send such a report.
+  </summary>
+</histogram>
+
 <histogram name="SSL.ExpectCTReportFailure" enum="NetErrorCodes">
   <owner>estark@chromium.org</owner>
   <summary>
@@ -54520,6 +54531,9 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
     whenever a TLS connection does not have valid Certificate Transparency
     information associated with it. This records the error code when Chrome
     fails to send an Expect CT report.
+
+    In M53 and earlier, the recorded error code was a negative integer; in M54
+    and later, the error code is positive.
   </summary>
 </histogram>