ROS 2软件包维护人员指南
ROS 2核心中的每个软件包都有一个或多个维护人员，负责维护软件包的整体健康状况。本指南介绍了ROS 2核心软件包维护人员的责任和一些信息。
目录
评论
所有提交到ROS 2核心仓库的代码都必须进行审核。审核会关注以下方面：
适用于该包的合适性
正确的代码
符合开发者指南要求：
为错误/功能添加测试
增加新功能的文档
清理持续集成运行
目标是默认分支（通常是“rolling”）
至少有一位维护者（非作者）的批准
持续集成
所有提交到ROS 2核心仓库的代码都必须通过持续集成进行运行。目前ROS 2有两个独立的持续集成系统，要求在合并之前必须通过这两个系统的PR（拉取请求）。
PR构建（https://build.ros2.org/view/Rpr）
ROS 2的PR（拉取请求）构建在每次打开拉取请求时会自动运行。这些构建只会构建和测试该软件包本身，不会构建任何依赖项，也不会构建依赖于该软件包的任何其他软件包。这些构建适用于快速反馈，以查看更改是否通过了代码检查、单元测试等。然而，它们存在两个主要问题：
这些构建不适用于多个代码库（因此不能用于添加或更改 API 等）
这些测试只在 Linux 上运行（它们无法在 macOS 或 Windows 上运行）
为了解决这两个问题，还有 CI 构建。
CI 构建（https://ci.ros2.org）
当打开拉取请求时，CI构建不会自动运行。软件包的维护人员之一必须手动请求执行CI构建，方法是访问https://ci.ros2.org/job/ci_launcher/。
默认情况下，以这种方式运行作业将在所有平台（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 后，它将自动与下一个 夜间构建版本 一起构建。强烈建议在合并拉取请求后检查夜间构建版本，以确保没有发生回归。
保持 CI 绿色
运行测试的夜间任务通常比为单个拉取请求执行的任务要全面得多。因此，在夜间构建版本中可能会发生在 CI 任务中未出现的回归。包维护者有责任在以下位置检查其包是否存在回归：
如发现任何问题，请在相关仓库上开启新的问题(issue)和/或拉取请求(pull requests)。
发布版本
为了将新功能和错误修复传递给最终用户，软件包维护人员必须定期发布软件包（也可以根据其他维护人员的要求按需发布）。
如在开发人员指南的 版本号规范 中所述，ROS 2 软件包遵循语义化版本号规范。
在ROS术语中，发布分为两个不同的步骤：制作源代码版本和制作二进制版本。
源代码发布
源代码发布会在相关的代码库中创建一个变更日志和一个标签。
该过程从使用以下命令生成或更新 CHANGELOG.rst 文件开始：
$ catkin_generate_changelog
如果代码库中的一个或多个软件包不包含 CHANGELOG.rst 文件，则需要添加 --all 选项，以便为每个软件包填充所有先前的提交。catkin_generate_changelog 命令将简单地使用代码库中的提交日志填充这些文件。由于这些提交日志并不总是适合用作变更日志，建议编辑 CHANGELOG.rst 并将其编辑为更易读的格式。编辑完成后，重要的是将更新的 CHANGELOG.rst 文件提交到代码库中。
下一步是使用以下命令在package.xml和changelog文件中增加版本号：
$ catkin_prepare_release
该命令将查找存储库中的所有软件包，检查changelog是否存在，检查是否有未提交的本地更改，增加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 软件库发布到 Humble 发行版，命令如下：
$ bloom-release --track humble --rosdistro humble rclcpp
此命令将获取发布软件库，进行必要的更改以进行发布，将更改推送到发布软件库，最后会向 https://github.com/ros/rosdistro 发送一个拉取请求。
向已发布的发行版进行回溯
所有传入的更改应首先落在开发分支上。一旦将更改合并到开发分支上，可以考虑将其回溯到发布的发行版中。然而，任何回溯的代码都不能在发布的发行版中破坏`API <https://en.wikipedia.org/wiki/API>`__或`ABI <https://en.wikipedia.org/wiki/Application_binary_interface>`__。如果可以在不破坏API或ABI的情况下回溯更改，那么应创建一个针对相应分支的新拉取请求。新的拉取请求应添加到 https://github.com/orgs/ros2/projects 上的相应发行版项目板中。新的拉取请求应按照之前的步骤运行，但要确保针对CI等问题的目标分发。
回应问题
软件包维护者还应查看存储库上的问题，并对用户遇到的问题进行分类。
对于看起来像问题的问题，应该关闭该问题并将用户重定向到 Robotics Stack Exchange。
如果某个问题看起来像是一个问题，但与该特定存储库无关，则应使用GitHub的“转移问题”按钮将其移至相应的存储库中。
如果报告者没有提供足够的信息来确定问题的原因，则应向报告者请求更多信息。
如果这是一个新功能，请使用“help-wanted”标记该问题。
应重现任何剩余的问题，并确定它们是否真的是一个错误。如果是错误，请高度欢迎修复。