反向移植和 Ansible 集成
每个集合社区可以设置自己的规则和工作流程来管理拉取请求、错误报告、文档问题和功能请求,以及添加和替换维护者。维护者根据以下内容审查和合并拉取请求:
集合维护者
集合范围的维护者是具有集合中write
或更高访问级别的贡献者。他们拥有提交权限,可以合并拉取请求以及其他权限。
当集合维护者认为对文件的贡献足够重要时(例如,修复复杂的错误、添加功能、提供定期审查等),他们可以邀请作者成为模块维护者。
模块维护者
模块范围的维护者存在于拥有集合机器人的集合中,例如community.general 和 community.network。
成为模块维护者是成为集合维护者之前的阶段。模块维护者是在.github/BOTMETA.yml
中列出的贡献者。范围可以是任何文件(例如,模块或插件)、目录或存储库。因为在大多数情况下范围是模块或模块组,所以我们称这些贡献者为模块维护者。当创建与他们维护的文件相关的 issue/pull 请求时,集合机器人会通知模块维护者。
模块维护者通过集合机器人间接拥有提交权限。当两个模块维护者在更改他们维护的模块的拉取请求上使用关键词shipit
、LGTM
或+1
进行评论时,集合机器人会自动合并拉取请求。
有关集合机器人及其界面的更多信息,请参阅集合机器人概述。
发布集合
集合维护者负责发布集合的新版本。通常,发布集合包括:
计划和公告。
生成变更日志。
创建发布 Git 标签并推送。
通过Zuul 仪表板在Ansible Galaxy上自动发布发行版 tarball。
最终公告。
详情请参见发布集合。
反向移植
集合维护者根据集合的语义版本控制和发布策略,将合并的拉取请求反向移植到稳定分支。
手动反向移植过程类似于ansible-core 反向移植指南。
为方便起见,可以使用 GitHub 机器人(例如,使用Patchback 应用)和标签自动实现反向移植,就像在community.general 和 community.network 中所做的那样。
将集合包含到 Ansible 中
如果集合未包含在 Ansible 中(未与 Ansible 包一起提供),维护者可以通过在ansible-collections/ansible-inclusion 存储库下创建一个讨论来提交集合以供包含。更多信息,请参见存储库的 README和Ansible 社区包集合要求。
辞去集合维护者职务
时代在变,您继续担任集合维护者的能力也可能发生变化。我们要求您不要默默地辞去职务。
如果您觉得您没有时间继续维护您的集合,您应该:
告知其他维护者。
如果集合位于
ansible-collections
组织下,也请告知相关的实时聊天,IRC 或 Matrix 上的community
聊天频道,或通过电子邮件[email protected]
。查看集合中的活跃贡献者,在他们中间寻找新的维护者。与其他维护者或社区团队讨论潜在的候选人。
如果您未能找到替代者,请在集合中创建一个置顶的 issue,宣布该集合需要新的维护者。
通过Bullhorn 新闻通讯发布相同的公告。
请留下来讨论其他维护者或社区团队找到的潜在候选人。
记住,这是一个社区,因此您将来可以随时回来。