ROS 2 核心维护者指南
ROS 2 核心中的每个软件包都有一个或多个维护者，负责软件包的总体运行状况。 本指南提供了有关 ROS 2 核心软件包维护者职责的一些信息。
审核
所有进入 ROS 2 核心存储库的代码都必须经过审核。 审核要求：
持续集成
所有进入 ROS 2 核心存储库的代码都必须通过持续集成运行。 ROS 2 目前有两个独立的 CI 系统，要求 PR 在合并之前通过这两个系统。
PR 构建 (https://build.ros2.org/view/Rpr)
每次打开拉取请求时，ROS 2 PR（拉取请求）构建都会自动运行。 这些构建仅运行此存储库的构建和测试。 这意味着它不会构建任何依赖项，也不会构建任何依赖于此存储库中的包的存储库。 这些构建适用于快速反馈，以查看更改是否通过了 linters、单元测试等。
它们有两个主要问题：
这些构建无法跨多个存储库工作（因此无法添加或更改 API 等）
这些测试仅在 Linux 上运行（无法在 macOS 或 Windows 上运行）
为了解决这两个问题，还有 CI 构建。
CI 构建 (https://ci.ros2.org)
打开拉取请求时，CI 构建不会自动运行。 存储库的维护者之一必须通过转到 https://ci.ros2.org/job/ci_launcher/ 手动请求完成 CI 构建。
默认情况下，以这种方式运行作业将在所有平台（Linux、macOS 和 Windows）上为所有软件包（目前超过 300 个）构建和运行测试。 由于完整运行可能需要数小时并占用 CI 机器，因此建议此处的所有运行都限制构建和测试的包数量。 这可以通过使用 colcon 参数“–packages-up-to”、“–packages-select”、“–packages-above-and-dependencies”、“–packages-above”等来实现。 有关可使用的标志的更多示例，请参阅“colcon 文档 <https://colcon.readthedocs.io/en/released/user/how-to.html#build-only-a-single-package-or-selected-packages>” 。 有关如何使用 CI 机器的更多文档，请访问 https://github.com/ros2/ci/blob/master/CI_BUILDERS.md。
合并拉取请求
如果以下所有条件都为真，则可以合并拉取请求：
DCO 机器人报告通过结果
PR 构建报告通过结果
CI 构建在所有平台上报告通过结果
代码已由至少一名维护者审查和批准
PR 合并后，它将自动与下一个 nightlies 一起构建。
强烈建议在合并拉取请求后检查 nightlies，以确保没有发生回归。
保持 CI 绿色
运行测试的夜间作业通常比单个拉取请求的作业更全面。 因此，夜间作业中可能会出现 CI 作业中未发现的回归。 维护人员有责任在以下位置检查其软件包中的回归：
对于发现的任何问题，应在相关存储库上打开新问题和/或拉取请求。
发布
为了向最终用户提供新功能和错误修复，维护人员必须定期发布存储库（也可以根据需要向其他维护人员请求发布）。
如 开发者指南 中所述，ROS 2 软件包遵循 semver 的版本号。
用 ROS 术语来说，发布包括两个不同的步骤：制作源代码版本，然后制作二进制版本。
源代码版本
源代码版本会在相关存储库中创建更改日志和标签。
该过程首先使用以下命令生成或更新 CHANGELOG.rst 文件：
$ catkin_generate_changelog
如果存储库中的一个或多个包不包含 CHANGELOG.rst，请添加 --all 选项以填充每个包的所有先前提交。
catkin_generate_changelog 命令将简单地使用存储库中的提交日志填充文件。
由于这些提交日志并不总是适合变更日志，因此建议编辑 CHANGELOG.rst 并对其进行编辑以使其更具可读性。
编辑完成后，将更新的 CHANGELOG.rst 文件提交到存储库非常重要。
下一步是使用以下命令在 package.xml 和变更日志文件中增加版本：
$ catkin_prepare_release
此命令将查找存储库中的所有软件包，检查变更日志是否存在，检查是否存在未提交的本地更改，增加 package.xml 文件中的版本，并使用 bloom 兼容标签提交/标记更改。 使用此命令是确保发布版本与 bloom 一致且兼容的最佳方法。 默认情况下，“catkin_prepare_release”将增加软件包的补丁版本，例如 0.1.1 -> 0.1.2。 但是，它也可以增加次要或主要编号，甚至可以设置精确的版本。 有关更多信息，请参阅“catkin_prepare_release”的帮助输出。
假设上述操作成功，则已进行源代码发布。
二进制版本
下一步是使用“bloom-release”命令创建二进制版本。 有关如何使用 bloom 的完整说明，请参阅 http://wiki.ros.org/bloom。 要执行存储库的二进制发布，请运行：
$ bloom-release --track <rosdistro> --rosdistro <rosdistro> <repository_name>
例如，要将“rclcpp”存储库发布到Rolling发行版，命令如下：
$ bloom-release --track rolling --rosdistro rolling rclcpp
此命令将获取发布存储库，进行必要的更改以进行发布，将更改推送到发布存储库，最后打开拉取请求到 https://github.com/ros/rosdistro 。
反向移植到已发布的发行版
所有传入的更改都应首先落在开发分支上。 将更改合并到开发分支后，可以考虑将其反向移植到已发布的发行版。 但是，任何反向移植的代码都不能破坏已发布发行版中的 API 或 ABI。 如果可以在不破坏 API 或 ABI 的情况下反向移植更改，则应创建针对相应分支的新拉取请求。 应将新的拉取请求添加到 https://github.com/orgs/ros2/projects 上的相应发行版项目板。 新的拉取请求应像以前一样运行所有步骤，但要确保针对 CI 等问题分布。
响应问题
软件包维护者还应查看存储库中的传入问题并对用户遇到的问题进行分类。
对于看起来像问题的问题，应关闭该问题并将用户重定向到 Robotics Stack Exchange 。
如果问题看起来像问题，但与此特定存储库无关，则应使用 GitHub“转移问题”按钮将其移动到适当的存储库。
如果报告者没有提供足够的信息来确定问题的原因，则应向报告者索取更多信息。
如果这是一项新功能，请用“help-wanted”标记该问题。
任何剩余的问题都应重现，并确定它们是否真的是错误。
如果是错误，非常感谢修复。
获取帮助
在对软件包进行维护时，可能会出现有关一般程序或个别问题的问题。
对于一般问题，请遵循：doc:贡献指南。
对于个别问题，请标记 ROS 2 GitHub 团队 (@ros/team)，团队中的某个人会查看。