diff --git a/source/Installation.rst b/source/Installation.rst index 55465c25ce..62c46fcb96 100644 --- a/source/Installation.rst +++ b/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 ` (recommended) * :doc:`binary archive ` -* RHEL 9 +* Red Hat Enterprise Linux 9 (amd64) * :doc:`RPM packages ` (recommended) * :doc:`binary archive ` -* Windows 10 +* Windows 10 (amd64) * :doc:`Windows Binary (VS 2019) ` diff --git a/source/The-ROS2-Project/Contributing/Developer-Guide.rst b/source/The-ROS2-Project/Contributing/Developer-Guide.rst index 18507c9e76..6dbb6c61ca 100644 --- a/source/The-ROS2-Project/Contributing/Developer-Guide.rst +++ b/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] ". - If backporting a subset of changes from one or multiple PRs, the title should be "[Distro] ". * 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 `_ 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 `__ 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 `__. 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 `, 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