Bug 1455353 Fix sphinx warnings in Telemetry documentation r=chutten
authorIssei Horie <is2ei.horie@gmail.com>
Sat, 21 Apr 2018 20:41:36 +0900
changeset 416031 766dd36bfd6d
parent 416030 11a2d91d1843
child 416032 d9515d63a7cf
push id102703
push usercbrindusan@mozilla.com
push dateFri, 27 Apr 2018 14:41:48 +0000
treeherdermozilla-inbound@d9515d63a7cf [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewerschutten
bugs1455353
milestone61.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1455353 Fix sphinx warnings in Telemetry documentation r=chutten
toolkit/components/telemetry/docs/collection/histograms.rst
toolkit/components/telemetry/docs/collection/hybrid-content.rst
toolkit/components/telemetry/docs/data/health-ping.rst
toolkit/components/telemetry/docs/fhr/dataformat.rst
toolkit/components/telemetry/docs/start/adding-a-new-probe.rst
--- a/toolkit/components/telemetry/docs/collection/histograms.rst
+++ b/toolkit/components/telemetry/docs/collection/histograms.rst
@@ -102,27 +102,29 @@ Declaring a Histogram
 
 Histograms should be declared in the `Histograms.json <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/Histograms.json>`_ file. These declarations are checked for correctness at `compile time <https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/gen_histogram_data.py>`_ and used to generate C++ code.
 
 The following is a sample histogram declaration from ``Histograms.json`` for a histogram named ``MEMORY_RESIDENT`` which tracks the amount of resident memory used by a process:
 
 
 .. code-block:: json
 
+  {
     "MEMORY_RESIDENT": {
       "record_in_processes": ["main", "content"],
       "alert_emails": ["team@mozilla.xyz"],
       "expires_in_version": "never",
       "kind": "exponential",
       "low": 32768,
       "high": 1048576,
       "n_buckets": 50,
       "bug_numbers": [12345],
       "description": "Resident memory size (KB)"
-    },
+    }
+  }
 
 Histograms which track timings in milliseconds or microseconds should suffix their names with ``"_MS"`` and ``"_US"`` respectively. Flag-type histograms should have the suffix ``"_FLAG"`` in their name.
 
 The possible fields in a histogram declaration are listed below.
 
 ``record_in_processes``
 -----------------------
 Required. This field is a list of processes this histogram can be recorded in. Currently-supported values are:
--- a/toolkit/components/telemetry/docs/collection/hybrid-content.rst
+++ b/toolkit/components/telemetry/docs/collection/hybrid-content.rst
@@ -24,17 +24,17 @@ 3. registering the probes after the libr
 4. using the API to send Telemetry.
 
 Granting the privileges
 -----------------------
 For security/privacy reasons `Mozilla.ContentTelemetry` will only work on a list of allowed secure origins. The list of allowed origins can be found in `browser/app/permissions <https://dxr.mozilla.org/mozilla-central/source/browser/app/permissions>`_ . A host needs to be given the ``hc_telemetry`` permission in order to be whitelisted.
 
 Example:
 
-.. code-block:: csv
+::
 
   origin  hc_telemetry  1 https://discovery.addons.mozilla.org
 
 Adding an entry to the ``permissions`` file requires riding the trains. If "go-faster" content requires
 granting permissions to a Mozilla page, it can do so by using the `permission manager <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIPermissionManager>`_
 
 .. code-block:: js
 
--- a/toolkit/components/telemetry/docs/data/health-ping.rst
+++ b/toolkit/components/telemetry/docs/data/health-ping.rst
@@ -76,17 +76,17 @@ This field lists the number of failed pi
 
 The recorded failure types are:
 
 * "eOK" - No error.
 * "eRequest" - There was some error in the request before we started to service it.
 * "eUnreachable" - The remote server was unreachable.
 * "eChannelOpen" - The connection failed when we tried to open the channel.
 * "eRedirect" - The connection failed when being redirected.
-* "abort" - What XMLHttpRequest means by "abort" (see `MDN <https://developer.mozilla.org/en-US/docs/Web/Events/abort>`_)
-* "timeout" - What XMLHttpRequest means by "timeout" (see `MDN <https://developer.mozilla.org/en-US/docs/Web/Events/timeout>`_)
+* "abort" - What XMLHttpRequest means by "abort" (see `MDN <https://developer.mozilla.org/en-US/docs/Web/Events/abort>`__)
+* "timeout" - What XMLHttpRequest means by "timeout" (see `MDN <https://developer.mozilla.org/en-US/docs/Web/Events/timeout>`__)
 
 This field is optional.
 
 .. note::
 
     Although both ``pingDiscardedForSize`` and ``sendFailure`` fields are optional, the health ping will only
     be submitted if one of this field not empty.
--- a/toolkit/components/telemetry/docs/fhr/dataformat.rst
+++ b/toolkit/components/telemetry/docs/fhr/dataformat.rst
@@ -1982,16 +1982,17 @@ numSuccessfulFills
 
 numTotalLoginsEncountered
     Number of times a login form was encountered by the user in the session.
 
 Example
 ^^^^^^^
 
 ::
+
     "org.mozilla.passwordmgr.passwordmgr": {
       "_v": 2,
       "numSavedPasswords": 32,
       "enabled": 1,
       "numNewSavedPasswords": 5,
       "numSuccessfulFills": 11,
       "numTotalLoginsEncountered": 23,
     }
--- a/toolkit/components/telemetry/docs/start/adding-a-new-probe.rst
+++ b/toolkit/components/telemetry/docs/start/adding-a-new-probe.rst
@@ -1,33 +1,33 @@
 ============================
 Adding a new Telemetry probe
 ============================
 
 In Firefox, the Telemetry system collects various measures of Firefox performance, hardware, usage and customizations and submit it to Mozilla. This article provides an overview of what is needed to add any new Telemetry data collection.
 
 .. important::
 
-    Every new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`_ from a data collection peer. Just set the feedback? flag for one of the data peers. They try to reply within a business day.
+    Every new data collection in Firefox needs a `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection#Requesting_Approval>`__ from a data collection peer. Just set the feedback? flag for one of the data peers. They try to reply within a business day.
 
 What is your goal?
 ==================
 
 We have various :doc:`data collection tools <../collection/index>` available, each serving different needs. Before diving right into technical details, it is best to take a step back and consider what you need to achieve.
 
 Your goal could be to answer product questions like “how many people use feature X?” or “what is the error rate of service Y?”.
 You could also be focused more on answering engineering questions, say “which web features are most used?” or “how is the performance of engine Z?”.
 
 From there, questions you should ask are:
 
 - What is the minimum data that can answer your questions?
 - How many people do you need this data from?
 - Is data from the pre-release channels sufficient?
 
-This also informs the `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection>`_, which requires a plan for how to use the data. Data collection review is required for all new data collection.
+This also informs the `data collection review <https://wiki.mozilla.org/Firefox/Data_Collection>`__, which requires a plan for how to use the data. Data collection review is required for all new data collection.
 
 Data collection levels
 ======================
 
 Most of our data collection falls into one of two levels, *release* and *pre-release*.
 
 **Release data** is recorded by default on all channels, users need to explicitly opt out to disable it. This has `stricter constraints <https://wiki.mozilla.org/Firefox/Data_Collection#Requirements>`_ for what data we can collect. "Most" users submit this data.