本指南适用于 Bazel 开源项目的维护人员。
如果您希望为 Bazel 做贡献,请参阅为 Bazel 做贡献。
本页旨在:
- 充当项目的贡献流程的维护者可信来源。
- 在社区贡献者与项目维护者之间设定预期。
Bazel 的贡献者核心组拥有专门的子团队来管理该开源项目的方方面面。这些国家/地区包括:
- 发布流程:管理 Bazel 的发布流程。
- 绿色团队:打造一个健康规则和工具生态系统,
- 开发者体验园丁:鼓励外部人员贡献内容,审核问题并拉取请求,使我们的开发工作流更开放。
版本
持续集成
阅读针对 bazelbuild/持续集成代码库上的 Bazel CI 基础架构的绿色团队指南。
问题的生命周期
- 用户使用问题模板创建了问题,此时问题进入了未审核的待解决问题池。
- 开发者体验 (DevEx) 子团队轮替的成员正在审核问题。
- 如果问题不是 bug 或功能请求,DevEx 成员通常会关闭问题并将用户重定向到 StackOverflow 和 bazel-discuss,以提高问题的可见性。
- 如果问题属于社区拥有的某个规则代码库(如 rules_apple),DevEx 成员将将此问题转移到正确的代码库。
- 如果问题含糊不清或缺少信息,DevEx 成员会将问题分配回用户,要求提供更多信息后再继续。通常,如果用户未遵循问题模板,就会出现这种情况。
- 审核问题后,DevEx 成员会决定是否需要立即关注问题。如果存在这种情况,他们将分配 P0 优先级标签以及团队负责人列表中的所有者。
- DevEx 成员会为路由分配
untriaged
标签和仅一个团队标签。 - DevEx 成员还会根据问题类型分配一个
type:
标签,例如type: bug
或type: feature request
。 - 对于平台特有的问题,DevEx 成员会分配一个
platform:
标签,例如 Mac 特有的问题对应的platform:apple
。 - 如果问题优先级较低且可由新的社区贡献者处理,DevEx 成员会分配
good first issue
标签。在此阶段,问题会进入未分类的待解决问题池。
每个 Bazel 子团队最好对自己所拥有的标签的所有问题进行分类,最好每周一次。子团队将审核并评估问题,并尽可能提供解决方案。如果您是团队标签的所有者,请参阅此部分 了解详情。
问题解决后,便可将其关闭。
拉取请求的生命周期
- 用户创建拉取请求。
- 如果您是 Bazel 团队的成员,并在自己的领域发送 PR,则需自行分配您的团队标签并寻找最佳审核者。
- 否则,在日常分类中,DevEx 成员会分配一个团队标签和团队的技术主管 (TL) 进行路由。
- 团队负责人可以选择指定其他人来查看公共关系。
- 已分配的审核人员会审核 PR,并与作者合作,直到其获得批准或被弃用。
- 如果获得批准,审核人员会将 PR 的提交导入 Google 的内部版本控制系统,以供进一步测试。由于 Bazel 与 Google 在内部使用的构建系统相同,我们需要针对内部测试套件测试所有 PR 提交。正因如此,我们不会直接合并 PR。
- 如果导入的提交通过所有内部测试,则系统将压缩该提交并将其导出回 GitHub。
- 当提交合并到主实例时,GitHub 会自动关闭 PR。
我的团队拥有标签。该怎么做?
子团队需要对其拥有的标签中的所有问题进行分类,最好每周进行一次。
问题
- 按您的团队标签和
untriaged
标签过滤问题列表。 - 查看问题。
- 确定优先级并分配标签。
- 如果 DevEx 子团队是 P0,则问题可能已优先处理。如有需要,请重新确定优先顺序。
- 每个问题都需要有一个优先级标签。如果某个问题是 P0 或 P1,我们会认为问题已得到有效处理。
- 移除
untriaged
标签。
请注意,您必须是 bazelbuild 组织才能添加或移除标签。
拉取请求
- 按您的团队标签过滤拉取请求列表。
- 查看待处理的拉取请求。
- 可选:如果您获分配参与评价,但不符合该审核的条件,请重新分配相应的审核人员以执行代码审核。
- 与拉取请求创建者合作完成代码审核。
- 批准 PR。
- 确保所有测试均通过。
- 将补丁导入内部版本控制系统并运行内部提交前测试。
- 提交内部补丁。如果补丁提交并导出成功,GitHub 将自动关闭 PR。
优先级
维护人员将使用以下优先级对问题进行分类。
- P0 - 导致 Bazel 版本(减号候选版本)无法使用的主要功能,或严重影响 Bazel 项目的开发的服务中断服务。这包括新版本中引入的会导致大量用户流失的回归,或不符合重大变更政策的不兼容破坏性更改。没有实际的解决方法。
- P1 - 将在下一个版本中解决的严重缺陷或功能,或者会影响许多用户(包括 Bazel 项目的开发)的严重问题,但存在实际的解决方法。通常不需要立即采取措施。需求量较大,并已根据当前季度的路线图进行规划。
- P2 - 缺陷或功能应该已得到解决,但我们目前尚未进行处理。已发布的 Bazel 版本存在适度的发布问题,而用户需要解决的是在未来版本中发布的问题,并且/或者存在一个简单的解决方法。
- P3 - 所需的细微 bug 修复或增强功能,影响较小。不会优先考虑 Bazel 路线图或任何即将发布的版本,但鼓励社区贡献。
- P4 - 低优先级缺陷或不太可能被关闭的功能请求。如果受影响的用户较多,也可以保持开放以便重新确定优先级。
- ice-box
- 我们目前没有时间处理的问题,也没有时间接受贡献内容。我们会关闭这些问题,以指出没有人处理这些问题,但随着时间推移,如果有足够多的人受到影响,并且我们恰好有资源可以处理,我们将继续监控其有效性,并使其恢复有效。与往常一样,即使关闭该页面,您也可以添加评论或回应。
团队标签
team-Android
:针对 Android 团队的问题- 联系人:ahumesky
team-Bazel
:常规 Bazel 产品/策略问题- 联系人:sventiffe
team-CLI
:控制台界面- 联系人:meisterT
team-Configurability
:与可配置性团队有关的问题。包括:核心 build 配置和过渡系统。不包括:对新标志或现有标志的更改- 联系人:gregestren
team-Core
:Skyframe、bazel 查询、BEP、选项解析、bazelrc- 联系人:haxorz
team-Documentation
:文档团队的问题- 联系人:philomathing
team-ExternalDeps
:外部依赖项处理、Bzlmod、远程代码库、WORKSPACE 文件- 联系人:meteorcloudy
team-Loading-API
:build 文件和宏处理:标签、package()、可见性、glob- 联系人:brandjon
team-Local-Exec
:执行(本地)团队问题- 联系人:meisterT
team-OSS
:Bazel OSS 团队的问题:安装、发布流程、Bazel 打包、网站、文档基础架构- 联系人:meteorcloudy
team-Performance
:Bazel 性能团队的问题- 联系人:meisterT
team-Remote-Exec
:执行(远程)团队问题- 联系人:coeuvre
team-Rules-API
:用于编写规则/方方面面的 API:提供程序、Runfile、操作、工件- 联系人:comius
team-Rules-CPP
:C++ 规则(包括原生 Apple 规则逻辑)的问题- 联系人:oquenchil
team-Rules-Java
:Java 规则问题- 联系人:hvadehra
team-Rules-Python
:原生 Python 规则的问题- 联系人:rickeylev
team-Rules-Server
:Bazel 附带的服务器端规则问题- 联系人:comius
team-Starlark-Integration
:非 API Bazel + Starlark 集成。包括:Bazel 如何触发 Starlark 解释器、Stardoc、内置注入、字符编码。不包括:BUILD 或 .bzl 语言问题。- 联系人:brandjon
team-Starlark-Interpreter
:与 Starlark 解释器相关的问题(java.net.starlark 中的任何内容)。build 和 .bzl API 问题(代表 Bazel 与 Starlark 集成的问题)位于team-Build-Language
中。- 联系人:brandjon
对于新问题,我们弃用了 category: *
标签,取而代之的是团队标签。
如需查看完整的标签列表,请点击此处。