refactor!: fully switch to Diataxis system

BREAKING CHANGE: This will break pretty much every link to our docs.

Awhile back we agreed to try and implement the Diataxis documentation
system:
https://diataxis.fr/

However, we only moved a handful of docs over and have been in a mixed
state of having docs following two separate structures (if you can call
the old way a structure) ever since.

The goal of this PR is to re-organize all the docs in the old structured
over to the new Diataxis-based structure. There are plenty of docs that
don't fit neatly in one place or the other, so this PR often takes a
best guess at where it belongs.

This PR also doesn't split up any individual files, though it does
sometimes move docs from directories to different places.

conf.py

@@ -16,8 +16,8 @@ import os
 
 # -- Project information -----------------------------------------------------
 
-project = 'RelEng Docs'
-copyright = '2020, Mozilla Release Engineering'
+project = 'RelEng'
+copyright = '2023, Mozilla Release Engineering'
 author = 'Mozilla Release Engineering'
 
 
@@ -56,4 +56,11 @@ exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
 #
+html_title = "RelEng Docs"
 html_theme = 'sphinx_book_theme'
+html_theme_options = {
+    "logo": {
+        "image_light": "media/releng.png",
+        "image_dark": "media/releng-dark.png",
+    },
+}

explanations/balrog/Balrog-and-Scheduled-Changes.rst

@@ -53,7 +53,7 @@ changes for
 and it is worth searching for relevant entries in other places as
 update-verify is refactored in 2020.
 
-.. |scheduled change without signoffs| image:: /balrog/media/only_scheduled.png
-.. |signoff modal dialog| image:: /balrog/media/signoff_dialog.png
-.. |scheduled change with one signoff| image:: /balrog/media/one_signoff.png
-.. |scheduled change with two signoffs| image:: /balrog/media/all_signoffs.png
+.. |scheduled change without signoffs| image:: media/only_scheduled.png
+.. |signoff modal dialog| image:: media/signoff_dialog.png
+.. |scheduled change with one signoff| image:: media/one_signoff.png
+.. |scheduled change with two signoffs| image:: media/all_signoffs.png

explanations/balrog/os-de-support.rst

@@ -31,7 +31,7 @@ Create a new channel-switching mar
     mar -x switch-to-esr115.0-eol-mac.mar
     xz -c -d updatev3.manifest
 
-* Verify your mar. :ref:`update-testing` describes how to apply a mar manually.
+* Verify your mar. :doc:`/how-to/test/updates` describes how to apply a mar manually.
 * Sign the mar via adhoc_signing. See https://github.com/mozilla-releng/adhoc-signing/blob/main/signing-manifests/bug1835022.yml for a sample manifest. 
 
 Copy the channel-switching mar to archive.mozilla.org
@@ -189,7 +189,7 @@ and check that the response updates to the pinned build (eg. 20230605094751): ::
 Verify changes: Application behavior
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* :ref:`update-testing` describes how to apply a mar manually.
+* :doc:`/how-to/test/updates` describes how to apply a mar manually.
 * QA usually verifies Firefox update behavior on each affected platform using trial rules on the ``beta-localtest`` channel prior to Merge Day II.
 
 Stop running tests

explanations/balrog/update_to_last_good_build.rst

@@ -22,4 +22,4 @@ Once a new build contains the fix
 -  ``*-latest`` on mozilla-central
 -  the new build on devedition and mozilla-{beta,release}.
 
-.. |scheduled change without signoffs| image:: /balrog/media/big_red_button.png
+.. |scheduled change without signoffs| image:: media/big_red_button.png

explanations/best-practices/bug-triage.rst

@@ -1,5 +1,5 @@
-RelEng Bug Triage
-=================
+Bug Triage
+==========
 
 This page outlines the process for triaging open RelEng bugs in `Bugzilla <https://bugzilla.mozilla.org/home>`_. The procedure ensures a well-organized bug database, where each bug is appropriately tagged and prioritized, making full use of Mozilla's `Bugdash <https://bugdash.moz.tools/?component=Release+Engineering%3AApplications%3A+Mapper&component=Release+Engineering%3AApplications%3A+MozharnessCore&component=Release+Engineering%3AApplications%3A+Shipit&component=Release+Engineering%3AFirefox-CI+Administration&component=Release+Engineering%3AGeneral&component=Release+Engineering%3ARelease+Automation%3A+Bouncer&component=Release+Engineering%3ARelease+Automation%3A+L10N&component=Release+Engineering%3ARelease+Automation%3A+Other&component=Release+Engineering%3ARelease+Automation%3A+Signing&component=Release+Engineering%3ARelease+Automation%3A+Snap&component=Release+Engineering%3ARelease+Automation%3A+Updates&component=Release+Engineering%3ARelease+Automation%3A+Uploading&component=Release+Engineering%3ARelease+Requests#tab.triage>`_ triage tool.
 

explanations/best-practices/index.rst

@@ -6,5 +6,7 @@ Best Practices
 
     project-standards
     cross-training
+    bug-triage
     handoffs
     security
+    screen-sharing

explanations/best-practices/screen-sharing.rst

@@ -1,5 +1,5 @@
-Sharing your terminal
-=====================
+Sharing Terminal Sessions
+=========================
 
 Introduction
 ------------
@@ -9,7 +9,7 @@ check commands before they are entered. This may be due to the severity
 of an event and the risk if the commands are incorrect, or may be as
 straightforward as running a tutorial.
 
-While Vidyo can share screens (in the display sense), it's often not the
+While Zoom can share screens (in the display sense), it's often not the
 clearest for sharing a terminal window.
 
 Screen

explanations/index.rst

@@ -4,6 +4,12 @@ Explanations
 .. toctree::
    :maxdepth: 2
 
+   best-practices/index.rst
+   taskcluster/index.rst
+   Balrog & Updates <balrog/index.rst>
+   signing/index
    l10n.rst
+   mozharness.rst
    slide_decks.rst
    releng_environments.rst
+   tree-closing-window.rst

explanations/releng_environments.rst

@@ -53,7 +53,7 @@ Autograph Stage
 ~~~~~~~~~~~~~~~
 https://autograph-external.stage.autograph.services.mozaws.net
 
-Only for testing Autograph changes, so we should have *zero* signingscript or iscript signing formats that target Autograph Stage, except for any formats that are explicitly for testing Autograph Stage functionality (see :ref:`Testing_Autograph`).
+Only for testing Autograph changes, so we should have *zero* signingscript or iscript signing formats that target Autograph Stage, except for any formats that are explicitly for testing Autograph Stage functionality (see :doc:`/how-to/test/autograph`).
 
 Staging Shipit
 ~~~~~~~~~~~~~~

explanations/signing/index.rst

@@ -1,5 +1,5 @@
-Signing Articles and Documentation
-==================================
+Signing
+=======
 
 `Signing Mana page <https://mana.mozilla.org/wiki/pages/viewpage.action?spaceKey=RelEng&title=Signing>`__
 
@@ -9,9 +9,5 @@ Contents:
     :maxdepth: 2
 
     cert_levels_and_best_practices.md
-    Manually-sign-Android-APKs
-    create_new_release_signing_key
-    rotate_gpg_signing_key
     notarization
-    adhoc_signing
     inventory_and_safe

explanations/taskcluster/index.rst

@@ -0,0 +1,26 @@
+Firefox-CI & Taskcluster
+========================
+
+`Taskcluster`_ is Mozilla's home grown task execution framework and CI service.
+Mozilla runs two instances of Taskcluster; `Community`_ and `Firefox-CI`_.
+
+The ``community`` instance is operated by the Taskcluster team. It acts as a
+reference instance and primarily provides CI for projects that are adjacent to,
+but not strictly owned by MoCo.
+
+The ``firefox-ci`` instance is operated by Release Engineering. It provides CI
+for most MoCo products (including Firefox) and supporting repos.
+
+This section goes into some detail on core Taskcluster concepts, as well as
+Firefox-CI specific extensions that underpin Mozilla's CI.
+
+.. toctree::
+   :maxdepth: 2
+
+   how_tasks_are_triggered
+   scopes
+   rerun_vs_retrigger
+
+.. _Taskcluster: https://taskcluster.net/
+.. _Community: https://community-tc.services.mozilla.com/
+.. _Firefox-CI: https://firefox-ci-tc.services.mozilla.com/

explanations/tree-closing-window.rst

@@ -1,11 +1,5 @@
-.. _TCW:
-.. index:: 
-    single: Tree Closing Window
-    seealso: TCW; Tree Closing Window
-
-============================
-Tree Closing Window Planning
-============================
+Tree Closing Window
+===================
 
 The purpose of the Planning Procedure below is to state 
 the de facto agreement on the process for Tree Closing
@@ -15,7 +9,7 @@ italics*.
 .. _planning procedure:
 
 Planning Procedure
-==================
+------------------
 
 The goal is to have all the workload, durations, and personnel
 assignments done at least one week in advance of the TCW.
@@ -83,8 +77,13 @@ assignments done at least one week in advance of the TCW.
       MOC email is sent to everyone, we still post to newsgroups to
       reach community members of the development community.
 
-Execution of TCW
-================
+.. _CAB: https://mana.mozilla.org/wiki/display/MOC/Change+Advisory+Board
+.. _official release: https://wiki.mozilla.org/RapidRelease/Calendar
+.. _TCW Requests: https://mozilla.service-now.com/nav_to.do?uri=%2Fsys_report_template.do%3Fjvar_report_id%3D012b81bbdb0e26006c3fb1c0ef9619e1%26jvar_selected_tab%3DmyReports%26jvar_list_order_by%3D%26jvar_list_sort_direction%3D%26sysparm_reportquery%3D%26jvar_search_created_by%3D%26jvar_search_table%3D%26jvar_search_report_sys_id%3D%26jvar_report_home_query%3D
+.. _Internal Status: https://mozilla2.statuspage.io/
+
+Tree Closing Window Execution
+=============================
 
 The MOC administers the TCW. In general, the following generally occur:
 
@@ -104,10 +103,103 @@ The MOC administers the TCW. In general, the following generally occur:
 * All people involved with a tree closing part of the window remain
   on call until the trees are reopened.
 
-See :ref:`detailed checklist<TCW_Releng>` for actions to be taken.
+The checklist below is for before, during, and after a Tree Closing
+Window (TCW). These are the actions for almost any TCW. Most will
+benefit from specific additions.
 
-.. _CAB: https://mana.mozilla.org/wiki/display/MOC/Change+Advisory+Board
-.. _approved changes: https://mozilla.service-now.com/sys_report_template.do?jvar_report_id=dee1b20913c5aa00472ed2f18144b068&jvar_selected_tab=myReports&jvar_report_home_query=
-.. _official release: https://wiki.mozilla.org/RapidRelease/Calendar
-.. _TCW Requests: https://mozilla.service-now.com/nav_to.do?uri=%2Fsys_report_template.do%3Fjvar_report_id%3D012b81bbdb0e26006c3fb1c0ef9619e1%26jvar_selected_tab%3DmyReports%26jvar_list_order_by%3D%26jvar_list_sort_direction%3D%26sysparm_reportquery%3D%26jvar_search_created_by%3D%26jvar_search_table%3D%26jvar_search_report_sys_id%3D%26jvar_report_home_query%3D
-.. _Internal Status: https://mozilla2.statuspage.io/
+Wednesday Before
+----------------
+
+|_| Review any notes_ or bugs_ from prior TCWs that may be relevant.
+
+|_| Ensure the decision on "hard close" vs. "soft close" has been made.
+
+|_| Make sure all communications have gone out from the
+:ref:`planning procedure`.
+
+|_| Double check all bugs to be included, make sure you know how to
+recover from potential issues. The CAB list is the "source of truth".
+
+
+Day of TCW
+----------
+
+|_| Check and screenshot various dashboards to see what is current "normal".
+
+    - |_| Check `nagios service dashboard`__
+    - |_| Screenshot `nagios tactical dashboard`__
+    - |_| Screenshot `slavehealth`__
+
+__ https://nagios.mozilla.org/releng-scl3/cgi-bin/status.cgi?servicegroup=all&style=summary
+__ https://nagios.mozilla.org/releng-scl3/cgi-bin/tac.cgi
+__ https://secure.pub.build.mozilla.org/builddata/reports/slave_health/index.html
+
+|_| (optional) post message in IRC channels in advance. Usually #mobile,
+#developers, and #releng. Sample::
+
+    REMINDER - Trees close in about 1 hour for https://bugzil.la/1087431
+
+|_| Pull up local copies of all bugs and the spreadsheet, in case of
+network issues (planned, or unplanned)
+
+|_| Log in to the primary and backup IRC channels, see `IT IRC usage`__,
+make sure you have latest passwords.
+
+__ https://mana.mozilla.org/wiki/display/SYSADMIN/IRC+use+within+IT
+
+|_| Touch base with the MOC "on duty" person about 15 minutes before
+scheduled start of TCW.
+
+|_| Close the trees with the tracker bug URL mentioned. (For "soft tree
+closing" TCW:
+
+    - |_| Hard close autoland first.
+
+    - |_| Select all the open branches and add the message "TCW in
+      process, devs need to handle their own restarts", and "open" them
+      saving state.
+
+When TCW Done, Before Opening Trees
+-----------------------------------
+
+|_| Check `nagios dashboard`__ that all is as expected.
+
+__ https://nagios.mozilla.org/releng-scl3/
+
+|_| Check build API for `pending`__, `running`__, and `recent`__ to
+ensure those system are up.
+
+__ https://secure.pub.build.mozilla.org/buildapi/pending
+__ https://secure.pub.build.mozilla.org/buildapi/running
+__ https://secure.pub.build.mozilla.org/buildapi/recent
+
+|_| Check `Treeherder`__ to ensure it is up.
+
+__ https://treeherder.mozilla.org/
+
+|_| Reopen regular trees.
+
+|_| Reopen autoland (if closed for this TCW).
+
+|_| Update notes_ and file bugs_ as appropriate to capture any issues.
+Invite all TCW participants to do the same.
+
+Next Business Day
+-----------------
+
+|_| Review any notes_ or bugs_, and ensure they have enough context.
+
+|_| File Bugzilla tickets for any work that must be done. Put a link to
+the Bugzilla ticket in the GitHub issue, but do not close the issue
+until the bug is fixed.
+
+.. _notes: https://github.com/mozilla-releng/TCW-history/wiki
+.. _bugs: https://github.com/mozilla-releng/TCW-history/issues
+
+.. |_| raw:: html
+
+    <input type="checkbox" />
+
+.. |X| raw:: html
+
+    <input type="checkbox" checked />

how-to/create/index.rst

@@ -0,0 +1,11 @@
+Create
+======
+
+These guides are focused on implementing new functionality in our release pipelines.
+
+.. toctree::
+   :maxdepth: 1
+
+   new-scriptworker-script
+   new-package-format
+   mobile_automation_setup

how-to/create/mobile_automation_setup.rst

@@ -1,5 +1,5 @@
-How to automate nightly Google Play deployments
-===============================================
+Google Play Deployments
+=======================
 
 These instructions define how to set up an Android product for nightly
 deployments to the Google Play store.

how-to/create/new-package-format.rst

@@ -1,6 +1,5 @@
-
-Adding a package format
-=======================
+New Package Format
+==================
 
 There are some gotchas to pay attention to when adding a new package format, in
 particular related to bouncer.

how-to/create/new-scriptworker-script.rst

@@ -1,5 +1,5 @@
-How to add a new script to scriptworker-scripts
-===============================================
+New Scriptworker-Script
+=======================
 
 This procedure is based on the experience of `adding the pushmsixscript to scriptworker-scripts. <https://bugzilla.mozilla.org/show_bug.cgi?id=1745203>`__
 

how-to/handle-emergencies/expired-artifacts.rst

@@ -1,12 +1,9 @@
-Recover from tasks with expired artifacts
-=========================================
+Recover From Expired Artifacts
+==============================
 
 We sometimes have issues where a new Task or Task Graph depends on an older cached task whose key artifacts have expired. Recovering from this can be tricky, but the following steps should work for all cases:
 
-1) Rebuild the cached tasks with the "Rebuild Cached Tasks" action. This should be done against the most recent revision in the affected repository. For example, if the problem is happening on mozilla-beta you can visit https://treeherder.mozilla.org/jobs?repo=mozilla-beta, click the carat in the top right corner, select "Custom Push Action", and then Trigger the ``rebuild-cached-tasks`` action in the modal that pops up.
-
-2) Wait for the cached tasks to complete successfully. Until this has happened and the Taskcluster indexes have been updated, any new pushes or tasks created will potentially still use the old, broken cached tasks.
-
-3) Push a new commit to the affected branch. (This is not strictly necessary in all cases, but doing so avoids any possibility that older cached tasks will be used, so it is recommended unless you are very certain about what you are doing.)
-
-4) If you need tasks other than the ones created by the new push, create them now. For example, if your ultimate goal is to get a release shipped, it can now be scheduled.
+1. Rebuild the cached tasks with the "Rebuild Cached Tasks" action. This should be done against the most recent revision in the affected repository. For example, if the problem is happening on mozilla-beta you can visit https://treeherder.mozilla.org/jobs?repo=mozilla-beta, click the carat in the top right corner, select "Custom Push Action", and then Trigger the ``rebuild-cached-tasks`` action in the modal that pops up.
+2. Wait for the cached tasks to complete successfully. Until this has happened and the Taskcluster indexes have been updated, any new pushes or tasks created will potentially still use the old, broken cached tasks.
+3. Push a new commit to the affected branch. (This is not strictly necessary in all cases, but doing so avoids any possibility that older cached tasks will be used, so it is recommended unless you are very certain about what you are doing.)
+4. If you need tasks other than the ones created by the new push, create them now. For example, if your ultimate goal is to get a release shipped, it can now be scheduled.

how-to/handle-emergencies/index.rst

@@ -0,0 +1,15 @@
+Handle Emergencies
+==================
+
+Sometimes releases don't go as planned and we need to step in and make manual
+interventions. This section outlines some How-To guides on procedures that might
+help in such circumstances.
+
+.. toctree::
+   :maxdepth: 1
+
+   manual-release
+   manually-beetmove
+   manually-generate-partials
+   purge-partials-cache
+   expired-artifacts

how-to/index.rst

@@ -4,10 +4,13 @@ How To
 .. toctree::
    :maxdepth: 2
 
-   Add a scriptworker-script <add-scriptworker-script>
-   Manage L10n <l10n/index>
-   partner-repacks
    Release <release/index>
-   Manual update testing <update-testing>
-   Manually submit a release with the Ship It API <manual-release>
-   expired-artifacts
+   releaseduty/index
+   taskcluster/index
+   handle-emergencies/index
+   rotate/index
+   troubleshoot/index
+   test/index
+   create/index
+   Manage L10n <l10n/index>
+   Upload to Internal Pypi <https://wiki.mozilla.org/ReleaseEngineering/How_To/Upload_to_internal_Pypi>

how-to/release/addons/index.rst

@@ -6,3 +6,5 @@ Addons
 
     langpacks
     xpi-signing
+    openh264
+    widevine

how-to/release/addons/widevine.rst

@@ -171,6 +171,7 @@ Create a new rule to use the release you just created:
 Deployment usually proceeds in a series of steps over several days. Usually the Media team requests initial
 deployment to only the nightlytest channel, then the nightlytest and nightly channels, then also the beta channel, etc.
 To implement this (assuming an existing default Widevine rule with priority 420):
+
     - create a rule for nightlytest with priority 425
     - when requested to add nightly, create a new rule for the nightly channel with priority 425
     - when requested to add beta, create a new rule for beta with priority 425
@@ -205,5 +206,5 @@ https://aus5.mozilla.org/update/3/GMP/98.0/20180802174131/WINNT_x86_64-msvc-x64/
   works from Balrog's point of view, Firefox doesn't send this piece of
   data.
 
-.. |Balrog rule| image:: /procedures/misc-operations/widevine-balrog-rule.png
+.. |Balrog rule| image:: /media/widevine-balrog-rule.png
 

how-to/release/adhoc_signing.rst

@@ -1,4 +1,4 @@
-Adhoc signing
+Adhoc Signing
 =============
 
 Requestors should follow the `how to request an ad-hoc signature doc <https://github.com/mozilla-releng/adhoc-signing/blob/master/docs/how-to-request.md>`_.

how-to/release/firefox/index.rst

@@ -166,3 +166,12 @@ Shipit
 
 Shipit is used to initiate, track, and sign off on Firefox releases for each of the various stages. `Shipit
 <https://github.com/mozilla-releng/shipit>`_ is a web app.
+
+Off-Cycle Releases
+------------------
+
+.. toctree::
+   :maxdepth: 1
+
+   partner-repacks
+   off-cycle-partner-repacks-and-funnelcake

how-to/release/index.rst

@@ -6,4 +6,7 @@ This section contains how-to guides on releasing Mozilla's products.
 .. toctree::
    :maxdepth: 2
 
+   Firefox <firefox/index>
    Mozilla VPN <mozillavpn>
+   addons/index
+   Adhoc <adhoc_signing>

how-to/releaseduty/desktop/esr-to-esr-updates.rst

@@ -80,8 +80,8 @@ cause them to apply to any channel starting with ``esr``. These will be subject
 Once they've been made live you should also delete the ``esr-localtest`` rules, as they
 have been superceded by the new ``esr*`` rules.
 
-.. |platform-deprecation| image:: /procedures/release-duty/desktop/platform-deprecation.png
-.. |watershed| image:: /procedures/release-duty/desktop/watershed.png
+.. |platform-deprecation| image:: /media/platform-deprecation.png
+.. |watershed| image:: /media/watershed.png
 
 
 The Snap case

how-to/releaseduty/index.rst

@@ -1,5 +1,5 @@
-Release Duty
-============
+Perform Release Duty
+====================
 
 More detailed information on specific ReleaseDuty topics:
 
@@ -8,10 +8,8 @@ More detailed information on specific ReleaseDuty topics:
     :glob:
 
     desktop/*
-    mobile/*
     merge-duty/*
     interrupt-duty
-    ../../taskcluster/fxci_upgrades
 
 ReleaseDuty is a role within the Release Engineering team. It is conducted on a rolling rotation matching one person
 against one release cycle (currently 4 weeks). Below you will find a description of the expectations and resources

how-to/rotate/index.rst

@@ -0,0 +1,11 @@
+Rotate
+======
+
+Releng is responsible for rotating various keys and secrets from time to time.
+This section outlines How-To guides on how to handle them.
+
+.. toctree::
+   :maxdepth: 1
+
+   Firefox GPG Signing Key <gpg_signing_key>
+   hg-cert

how-to/taskcluster/index.rst

@@ -1,10 +1,9 @@
 .. _taskcluster:
 
-========================================
-Taskcluster Administration and Debugging
-========================================
+Administer Firefox-CI
+=====================
 
-Specifically for the FirefoxCI cluster.
+These external docs are relevant to Mozilla's Firefox-CI Taskcluster instance:
 
 - `Taskcluster docs`_
 - `Taskgraph docs`_
@@ -21,19 +20,15 @@ Specifically for the FirefoxCI cluster.
 .. _Rotate CoT keys: https://mana.mozilla.org/wiki/display/RelEng/Chain+of+Trust+key+rotation?flashId=459232040
 
 .. toctree::
-    :maxdepth: 2
+    :maxdepth: 1
+    :caption: How-To Guides
     :glob:
 
     uploading_an_image
     troubleshooting_workers
     taskcluster_cli
-    rerun_vs_retrigger
     testing_relpro.md
-    scopes
     known_problems
     ci_admin
     fxci_upgrades
     tc_staging
-    how_tasks_are_triggered
-
-.. vim: nospell :

how-to/taskcluster/known_problems.rst

@@ -105,7 +105,7 @@ Workers are spinning up slowly
 
 First, see :ref:`troubleshooting_workers`.
 
-Second, as of 2022.01.26, we have had a number of issues with worker-manager. There is a single process that goes through worker pool by worker pool to spin workers up and down on demand. The Azure workers, in particular, take a long time to spin up and down, and these processes block spinning other pools up or down. There's not much we can do here except adjust our idle times, which isn't the ideal solution. Otherwise we wait for the Taskcluster team to fix the issues::
+Second, as of 2022.01.26, we have had a number of issues with worker-manager. There is a single process that goes through worker pool by worker pool to spin workers up and down on demand. The Azure workers, in particular, take a long time to spin up and down, and these processes block spinning other pools up or down. There's not much we can do here except adjust our idle times, which isn't the ideal solution. Otherwise we wait for the Taskcluster team to fix the issues:
 
 1. `Bug 1736329 - gecko-3/decision workers not taking tasks <https://bugzilla.mozilla.org/show_bug.cgi?id=1736329>`__
 2. `Bug 1735411 - windows 2004 test worker backlog (gecko-t/win10-64-2004) <https://bugzilla.mozilla.org/show_bug.cgi?id=1735411>`__