反向移植和 Ansible 集成

每个集合社区可以设置自己的规则和工作流程来管理拉取请求、错误报告、文档问题和功能请求,以及添加和替换维护者。维护者根据以下内容审查和合并拉取请求:

维护者可以分为两种:集合维护者模块维护者

集合维护者

集合范围的维护者是具有集合中write或更高访问级别的贡献者。他们拥有提交权限,可以合并拉取请求以及其他权限。

当集合维护者认为对文件的贡献足够重要时(例如,修复复杂的错误、添加功能、提供定期审查等),他们可以邀请作者成为模块维护者。

模块维护者

模块范围的维护者存在于拥有集合机器人的集合中,例如community.generalcommunity.network

成为模块维护者是成为集合维护者之前的阶段。模块维护者是在.github/BOTMETA.yml中列出的贡献者。范围可以是任何文件(例如,模块或插件)、目录或存储库。因为在大多数情况下范围是模块或模块组,所以我们称这些贡献者为模块维护者。当创建与他们维护的文件相关的 issue/pull 请求时,集合机器人会通知模块维护者。

模块维护者通过集合机器人间接拥有提交权限。当两个模块维护者在更改他们维护的模块的拉取请求上使用关键词shipitLGTM+1进行评论时,集合机器人会自动合并拉取请求。

有关集合机器人及其界面的更多信息,请参阅集合机器人概述

发布集合

集合维护者负责发布集合的新版本。通常,发布集合包括:

  1. 计划和公告。

  2. 生成变更日志。

  3. 创建发布 Git 标签并推送。

  4. 通过Zuul 仪表板Ansible Galaxy上自动发布发行版 tarball。

  5. 最终公告。

  6. 可选地,提交请求以将新的集合包含到 Ansible 包中

详情请参见发布集合

反向移植

集合维护者根据集合的语义版本控制和发布策略,将合并的拉取请求反向移植到稳定分支。

手动反向移植过程类似于ansible-core 反向移植指南

为方便起见,可以使用 GitHub 机器人(例如,使用Patchback 应用)和标签自动实现反向移植,就像在community.generalcommunity.network 中所做的那样。

将集合包含到 Ansible 中

如果集合未包含在 Ansible 中(未与 Ansible 包一起提供),维护者可以通过在ansible-collections/ansible-inclusion 存储库下创建一个讨论来提交集合以供包含。更多信息,请参见存储库的 READMEAnsible 社区包集合要求

辞去集合维护者职务

时代在变,您继续担任集合维护者的能力也可能发生变化。我们要求您不要默默地辞去职务。

如果您觉得您没有时间继续维护您的集合,您应该:

  • 告知其他维护者。

  • 如果集合位于ansible-collections组织下,也请告知相关的实时聊天,IRC 或 Matrix 上的community聊天频道,或通过电子邮件[email protected]

  • 查看集合中的活跃贡献者,在他们中间寻找新的维护者。与其他维护者或社区团队讨论潜在的候选人。

  • 如果您未能找到替代者,请在集合中创建一个置顶的 issue,宣布该集合需要新的维护者。

  • 通过Bullhorn 新闻通讯发布相同的公告。

  • 请留下来讨论其他维护者或社区团队找到的潜在候选人。

记住,这是一个社区,因此您将来可以随时回来。