Fix the building releases docs formatting.

maintainers/building_releases.rst

@@ -116,25 +116,23 @@ Each of these is checked out on the relevant branch of
 ``godot-build-scripts``. Older branches may have slight variations to
 the workflow described above.
 
-Some files in these folders are ``.gitignore``\ d but quite important: -
-``config.sh`` is generated by copying ``config.sh.in`` and filling in
-the blanks. It contains all the details needed to sign, notarize and
-publish our builds. It’s also the file which defines which image
-version/tag we’re using for those builds (e.g. ``4.3-f40``). - Signing
-keys for various platforms.
+Some files in these folders are ``.gitignore``\ d but quite important:
+
+* ``config.sh`` is generated by copying ``config.sh.in`` and filling in the blanks. It contains all the details needed to sign, notarize and publish our builds. It’s also the file which defines which image version/tag we’re using for those builds (e.g. ``4.3-f40``).
+* Signing keys for various platforms.
 
 Building the binaries
 ~~~~~~~~~~~~~~~~~~~~~
 
 The entry point to make builds is ``build.sh``, which is responsible
-for: - Downloading the dependencies in ``deps`` if missing. \* Note: If
-you update dependencies in the script or at their download location, the
-easiest way to ensure things are up-to-date is to delete ``deps`` and
-let ``build.sh`` download everything again. - Cloning the Godot Git repo
-in ``git`` (only needed the first time). - Validating that the specified
-branch or commit matches the version we claim to build with ``-v``. -
-Creating a tarball of the Godot branch or commit we specify with ``-g``.
-- Starting builds for all platforms sequentially.
+for:
+
+* Downloading the dependencies in ``deps`` if missing.
+    * Note: If you update dependencies in the script or at their download location, the easiest way to ensure things are up-to-date is to delete ``deps`` and let ``build.sh`` download everything again.
+* Cloning the Godot Git repo in ``git`` (only needed the first time).
+* Validating that the specified branch or commit matches the version we claim to build with ``-v``.
+* Creating a tarball of the Godot branch or commit we specify with ``-g``.
+* Starting builds for all platforms sequentially.
 
 Builds are done by invoking ``podman`` (RedHat’s better Docker
 interface) with relevant arguments and the respective scripts found in
@@ -182,10 +180,12 @@ Finally, the ``publish-release.sh`` script takes care of:
 -  Publish the NuGet packages to NuGet Gallery.
 -  Publish the Android library to MavenCentral.
 
-For stable builds only, it additionally uploads the release to: - GitHub
-at https://github.com/godotengine/godot \* This requires getting a
-GitHub write token for one of our accounts. @GodotBuilder doesn’t have
-write access to godotengine/godot for safety. - Steam - EGS - itch.io
+For stable builds only, it additionally uploads the release to:
+* GitHub at https://github.com/godotengine/godot
+    * This requires getting a GitHub write token for one of our accounts. @GodotBuilder doesn’t have write access to godotengine/godot for safety.
+* Steam
+* EGS
+* itch.io
 
 On Steam, EGS, and itch.io, the builds need to be published manually in
 their respective backends (including writing a release post for Steam
@@ -211,22 +211,19 @@ the ``screen`` session, disconnect, and later on reconnect and re-attach
 to the ongoing ``screen`` session which will have continued on the
 remote host.
 
-Basic commands to know: - ``screen``: Start a session. - ``screen -r``:
-Resume a previously detached session. If more than one are detached,
-you’ll need to specify a PID after ``-r``. - ``screen -r -d``: Resume a
-session that wasn’t properly detached (e.g. due to the connection timing
-out). - ``exit`` (within a ``screen`` session): Terminate the session,
-or if multiple virtual terminals were open, close the current one.
+Basic commands to know:
+
+* ``screen``: Start a session.
+* ``screen -r``: Resume a previously detached session. If more than one are detached, you’ll need to specify a PID after ``-r``.
+* ``screen -r -d``: Resume a session that wasn’t properly detached (e.g. due to the connection timing out).
+* ``exit`` (within a ``screen`` session): Terminate the session, or if multiple virtual terminals were open, close the current one.
 
 Within a ``screen`` session, commands can be issued using the Ctrl+A
 hotkey. This hotkey starts an input mode without visual feedback, which
-can take notably these commands: - C: Create a new virtual terminal in
-the current session. - D: Detach from the current session. - 0-9: Go to
-the n-th virtual terminal. When creating a new session, there is only
-one virtual terminal (0), but after using the C command, you can cycle
-between 0 and 1, etc. \* This is useful when one virtual terminal is
-busy with a multi-hour build, but you still want to do some checks in a
-separate terminal (e.g. ``tail -n 1 out/logs/*`` to review the
-progress).
+can take notably these commands:
+* ``C``: Create a new virtual terminal in the current session.
+* ``D``: Detach from the current session.
+* ``0-9``: Go to the n-th virtual terminal. When creating a new session, there is only one virtual terminal (0), but after using the C command, you can cycle between 0 and 1, etc.
+    * This is useful when one virtual terminal is busy with a multi-hour build, but you still want to do some checks in a separate terminal (e.g. ``tail -n 1 out/logs/*`` to review the progress).
 
 See ``man screen`` for more details and possibly cool tricks.