Cosmetic fixes for Developer Guide.

source/Installation.rst

@@ -18,6 +18,8 @@ Options for installing ROS 2 {DISTRO_TITLE_FULL}:
    Installation/Testing
    Installation/RMW-Implementations
 
+.. _binary-package-platforms:
+
 Binary packages
 ---------------
 
@@ -27,17 +29,17 @@ If you are not running any of the following operating systems you may need to bu
 
 We provide ROS 2 binary packages for the following platforms:
 
-* Ubuntu Linux - Noble Numbat (24.04)
+* Ubuntu Linux (amd64 / aarch64) - Noble Numbat (24.04)
 
   * :doc:`deb packages <Installation/Ubuntu-Install-Debs>` (recommended)
   * :doc:`binary archive <Installation/Alternatives/Ubuntu-Install-Binary>`
 
-* RHEL 9
+* Red Hat Enterprise Linux 9 (amd64)
 
   * :doc:`RPM packages <Installation/RHEL-Install-RPMs>` (recommended)
   * :doc:`binary archive <Installation/Alternatives/RHEL-Install-Binary>`
 
-* Windows 10
+* Windows 10 (amd64)
 
   * :doc:`Windows Binary (VS 2019) <Installation/Windows-Install-Binary>`
 

source/The-ROS2-Project/Contributing/Developer-Guide.rst

@@ -159,13 +159,11 @@ Guidelines for backporting PRs
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When changing an older version of ROS:
-
 * Make sure the features or fixes are accepted and merged in the rolling branch before opening a PR to backport the changes to older versions.
 * When backporting to older versions, also consider backporting to any other :doc:`still supported versions <../../Releases>`, even non-LTS versions.
 * If you are backporting a single PR in its entirety, title the backport PR "[Distro] <name of original PR>".
-  If backporting a subset of changes from one or multiple PRs, the title should be "[Distro] <description of changes>".
 * Link to all PRs whose changes you're backporting from the description of your backport PR.
-  In a Dashing backport of a Foxy change, you do not need to link to the Eloquent backport of the same change.
+* Package maintainers typically use `Mergifyio <https://mergify.com/>`_ to automatically backport PRs to downstream distributions when needed, however developers can still perform manual backporting operations as described above when necessary.
 
 Documentation
 ^^^^^^^^^^^^^
@@ -360,7 +358,8 @@ Pull requests
   As the opener of a pull-request, if you are working in a fork, checking the box to `allow edits from upstream contributors <https://github.com/blog/2247-improving-collaboration-with-forks>`__ will assist with the aforementioned.
   As a reviewer, also feel free to make more substantial improvements, but consider putting them in a separate branch (either mention the new branch in a comment, or open another pull request from the new branch to the original branch).
 
-* Any developer (the author, the reviewer, or somebody else) can merge any approved pull request.
+* Only maintainers and committers can merge approved pull requests into the mainline.
+  See the :doc:`current ROS PMC constituents and committers <../Governance>` for the list of people with merge permissions.
 
 Library versioning
 ^^^^^^^^^^^^^^^^^^
@@ -759,26 +758,16 @@ The build farm is located at `ci.ros2.org <https://ci.ros2.org/>`__.
 Every night we run nightly jobs which build and run all the tests in various scenarios on various platforms.
 Additionally, we test all pull requests against these platforms before merging.
 
-This is the current set of target platforms and architectures, though it evolves overtime:
-
-
-* Ubuntu 24.04 Noble
-
-  * amd64
-  * aarch64
-
-* Windows 10
-
-  * amd64
+Check :ref:`the current set of target platforms and architectures <binary-package-platforms>`, though it evolves overtime.
 
 There are several categories of jobs on the buildfarm:
 
-
 * manual jobs (triggered manually by developers):
 
   * ci_linux: build + test the code on Ubuntu
   * ci_linux-aarch64: build + test the code on Ubuntu on an ARM 64-bit machine (aarch64)
   * ci_linux_coverage: build + test + generation of test coverage
+  * ci_linux-rhel: build + test the code on Red Hat Enterprise Linux
   * ci_windows: build + test the code on Windows
   * ci_launcher: trigger all the jobs listed above
 
@@ -788,18 +777,21 @@ There are several categories of jobs on the buildfarm:
 
     * nightly_linux_debug
     * nightly_linux-aarch64_debug
+    * nightly_linux-rhel_debug
     * nightly_win_deb
 
   * Release: build + test the code with CMAKE_BUILD_TYPE=Release
 
     * nightly_linux_release
     * nightly_linux-aarch64_release
+    * nightly_linux-rhel_release
     * nightly_win_rel
 
   * Repeated: build then run each test up to 20 times or until failed (aka flakiness hunter)
 
     * nightly_linux_repeated
     * nightly_linux-aarch64_repeated
+    * nightly_linux-rhel_repeated
     * nightly_win_rep
 
   * Coverage:
@@ -812,6 +804,7 @@ There are several categories of jobs on the buildfarm:
 * packaging (run every night; result is bundled into an archive):
 
   * packaging_linux
+  * packaging_linux-rhel
   * packaging_windows
 
 Two additional build farms support the ROS / ROS 2 ecosystem by providing building of source and