ROS 2包维护者指南 [待校准@6336]

ROS 2核心中的每个包都有一个或多个维护人员，负责包的总体运行状况。本指南提供了有关ROS 2核心包维护者职责的一些信息。 [待校准@6337]

评论 [待校准@6338]

必须检查所有传入ROS 2核心仓库的代码。该评论正在寻找: [待校准@6339]

持续集成 [待校准@6350]

所有进入ROS 2核心仓库的代码必须通过持续集成运行。ROS 2目前有两个独立的CI系统，并且要求PRs在合并之前通过这两个系统。 [待校准@6351]

公共关系构建 (https:// build.ros2.org/view/Rpr) [待校准@6352]

ROS 2 PR (拉取请求) 构建在每次打开拉取请求时运行自动调用y。这些构建运行此包的构建和测试，并且仅运行此包。这意味着它不构建任何依赖项，也不构建依赖于此包的任何包。这些构建有利于快速反馈，以查看更改是否通过了冬天，单元测试等。它们有两个主要问题: [待校准@6353]

  • 这些构建不工作多仓库 (所以无法添加或更换API等) [待校准@6354]

  • 这些测试仅在Linux上运行 (它们不会在macOS或Windows上运行) [待校准@6355]

为了解决这两个问题，还有CI构建。 [待校准@6356]

CI构建 (https:// ci.ros2.org) [待校准@6357]

当拉取请求打开时，CI构建不会自动调用y。包的维护者之一必须通过转到https:// CI.ros2.org/job/ci _ launcher/手动请求完成ci构建。 [待校准@6358]

默认情况下，以这种方式运行作业将在所有平台 (Linux、macOS和Windows) 上构建和运行所有包 (当前> 300) 的测试。由于完全运行可能需要花费许多小时并绑定CI机器，因此建议此处的所有运行都限制构建和测试的包的数量。这可以通过使用colcon参数 --packages-up-to 、 --packages-select 、 --packages-above-and-dependencies 、 --packages-above 等来实现。有关可使用标志的更多示例，请参见 colcon documentation 。进一步文件如何使用CI机械提供https://github.com/ros2/ci/blob/主/CI_BUILDERS.md。 [待校准@6359]

合并拉取请求 [待校准@6360]

如果满足以下所有条件，则可以合并拉取请求: [待校准@6361]

合并PR后，它将自动调用y与下一个 nightlies 一起构建。强烈建议在合并拉取请求后检查夜生活，以确保没有发生回归。 [待校准@6366]

保持CI绿色 [待校准@6367]

运行测试的夜间作业通常比对单个拉取请求的调用要全面得多。因此，可能存在在夜间发生的回归，而在CI作业中看不到。包维护人员有责任在以下位置检查其包中的回归: [待校准@6368]

对于发现的任何问题，应打开相关仓库的新问题和/或拉取请求。 [待校准@6373]

制作发行版本 [待校准@6374]

为了向最终用户提供新功能和错误修复，包维护人员必须定期调用y发布包 (也可以要求其他维护人员按需发布包)。 [待校准@6375]

ROS版本包括两个不同的步骤: 制作源文件版本，然后制作二进制版本。 [待校准@6376]

源发布 [待校准@6377]

源文件在相关仓库中创建变更日志和标签。 [待校准@6378]

该过程通过使用以下命令生成或更新CHANGELOG.rst文件开始: [待校准@6379]

$ catkin_generate_changelog

如果仓库中的一个或多个包没有包含CHANGELOG.rst，请添加 --all 选项以填充每个包的所有先前提交。 catkin_generate_changelog 命令将简单地用仓库中的提交日志填充文件。由于这些提交日志并不总是适合变更日志，因此建议编辑变更日志。rst并对其进行编辑以使其更具可读性。编辑完成后，将更新的CHANGELOG.rst文件提交到仓库非常重要。 [待校准@6380]

下一步是使用以下命令修改package.xml和changelog文件中的版本: [待校准@6381]

$ catkin_prepare_release

此命令将找到仓库中的所有包，检查变更日志是否存在，检查没有未提交的本地更改，增加包中的版本。xml文件，并使用与bloom兼容的标记提交/标记更改。使用此命令是确保发布版本与bloom一致和兼容的最佳方法。默认情况下， catkin_prepare_release 会碰撞包的补丁版本，例如0.1.1 -> 0.1.2。然而，它也可以碰撞次要或主要数字，甚至有一个精确的版本集。有关更多信息，请参见 catkin_prepare_release 的帮助输出。 [待校准@6382]

假设上述操作成功，则已发布源文件。 [待校准@6383]

二进制发布 [待校准@6384]

下一步是使用 bloom-release 命令创建二进制版本。有关如何使用bloom的完整说明，请参阅http://wiki.ros.org/bloom.要执行包的二进制发布，请运行: [待校准@6385]

$ bloom-release --track <rosdistro> --rosdistro <rosdistro> <repository_name>

例如，要将 rclcpp 仓库分配给Foxy，命令是: [待校准@6386]

$ bloom-release --track foxy --rosdistro foxy rclcpp

此命令将获取发布仓库，进行必要的更改以进行发布，将更改推送到发布仓库，最后打开拉取请求以https://github.com/ros/rosdistro。 [待校准@6387]

返回到已发布的发行版 [待校准@6388]

所有收到的变更应首先登陆开发版本分支机构。将更改合并到开发版本分支后，可以考虑将其反向移植到已发布的发行版。然而，任何反向移植的代码不得在发布的发行版中破坏 API or ABI 。如果可以在不破坏API或ABI的情况下反向移植更改，则应创建针对适当分支的新拉取请求。新请求应添加到适当分布工程板在https://github.com/orgs/ ros2/项目。新的拉取请求应该像以前一样运行所有步骤，但是要确保针对CI等问题的分布。 [待校准@6389]

回应问题 [待校准@6390]

包维护人员还应查看仓库中的传入问题，并对用户遇到的问题进行分类。 [待校准@6391]

问题像问题，应关闭用户重定向到https://answers.ros.org。 [待校准@6392]

如果一个问题看起来像一个问题，但与这个特定的仓库无关，应该使用GitHub "Transfer issue" 按钮将其移动到适当的仓库。 [待校准@6393]

如果报告者没有提供足够的信息来确定问题的原因，应要求报告者提供更多的信息。 [待校准@6394]

如果这是一项新功能，请用 “需要帮助” 标记该问题。 [待校准@6395]

任何剩余的问题都应该被复制，并确定它们是否真的是一个错误。如果是错误，则非常感谢修复。 [待校准@6396]

获得帮助 [待校准@6397]

在对包进行维护时，可能会出现关于一般程序或个别问题的问题。 [待校准@6398]

对于一般问题，请遵循 contributing guidelines 。 [待校准@6399]

关于个人问题的问题，请标记ROS 2 GitHub团队 (@ ros/团队)，团队中的某个人会看一看。 [待校准@6400]