本指南面向 Bazel 开源项目的维护者。
如果您希望为 Bazel 做出贡献,请改为参阅为 Bazel 做出贡献。
本页旨在:
- 作为维护者项目贡献的可信来源 过程。
- 为社区贡献者和项目维护者设定预期。
Bazel 的核心贡献者团队拥有专门的子团队来管理开源项目的各个方面。它们是:
- 发布流程:管理 Bazel 的发布流程。
- Green Team:推动由规则和工具组成的健康生态系统。
- 开发者体验园丁:鼓励外部贡献、审核 问题和拉取请求,使我们的开发工作流更加开放。
版本
持续集成
请参阅 bazelbuild/continuous-integration 代码库中 Green 团队关于 Bazel CI 基础架构的指南。
问题的生命周期
- 用户通过选择某个问题模板创建问题,该问题会进入未审核的未解决问题池。
- 开发者体验 (DevEx) 子团队轮流中的一名成员负责审核
问题。
- 如果问题不是 bug 或功能请求,DevEx 团队成员通常会关闭该问题,并将用户重定向到 StackOverflow 和 bazel-discuss,以便提高问题的曝光度。
- 如果问题属于 例如 rules_apple, DevEx 成员会转移此问题 正确的代码库
- 如果问题含糊不清或缺少信息,DevEx 团队成员会将问题重新分配给用户,要求用户提供更多信息,然后再继续处理。这种情况通常发生在用户未选择正确的 问题模板 {: .external} 或提供的信息不完整。
- 在审核问题后,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) 以进行转派。
- TL 可以选择将 PR 分配给其他人进行审核。
- 指定的审核者会审核 PR,并与作者合作,直到 PR 获得批准或被舍弃。
- 如果获得批准,审核人员会将 PR 的提交内容导入到 Google 的内部版本控制系统,以进行进一步测试。由于 Bazel 与 Google 内部使用的构建系统相同,因此我们需要针对内部测试套件测试所有 PR 提交内容。这就是我们不直接合并 PR 的原因。
- 如果导入的提交通过了所有内部测试,系统会合并该提交并将其导出回 GitHub。
- 提交内容合并到主分支后,GitHub 会自动关闭 PR。
我的团队拥有一个标签。该怎么做?
子团队需要对他们拥有的标签中的所有问题进行分类, 最好每周更新一次
问题
- 按团队标签和
untriaged
标签过滤问题列表。 - 查看问题。
- 确定优先级并分配标签。
- 如果此问题属于 P0。如有必要,请重新确定优先级。
- 每个问题都需要有且只有一个优先级标签。如果 问题为 P0 或 P1,我们假定问题已得到有效处理。
- 移除
untriaged
标签。
请注意,您需要在 bazelbuild 来添加或移除标签。
拉取请求
- 按团队标签过滤拉取请求列表。
- 查看未处理的拉取请求。
- 可选:如果您被指派接受审核,但不是您合适的人选 请重新指定相应的审核员来执行代码审核。
- 与拉取请求创建者合作完成代码审核。
- 批准 PR。
- 确保所有测试均通过。
- 将补丁导入内部版本控制系统,并运行内部提交前检查。
- 提交内部补丁。如果补丁成功提交并导出, GitHub 将自动关闭 PR。
优先级
维护人员将使用以下优先级定义来进行分类 问题。
- P0 - 导致 Bazel 版本(不包括候选版本)无法使用的重大功能故障,或导致 Bazel 项目开发严重受影响的服务故障。这包括新版本中引入的、会导致阻止 或者是发生了不兼容的重大更改, 符合重大 更改 政策。不存在实际的权宜解决方法。
- P1 - 严重缺陷或 应该在下一版本中解决的功能,或是需要改进的 影响许多用户(包括 Bazel 项目的开发),但 有实际解决方法。通常不需要立即采取措施。在 需求增加,并且已规划在当前季度的路线图中。
- P2 - 应解决的缺陷或功能,但我们目前不予处理。中等投放问题 使用以下发布的 Bazel 版本 并/或有其他简单的解决方法。
- P3 - 理想的小 bug 进行小幅修正或改进。未优先纳入 Bazel 路线图或 任何即将发布的新版本,不过我们鼓励观众投稿。
- P4 - 低优先级缺陷 或功能请求。也可以保持打开状态,以便在更多用户受到影响时重新确定优先级。
- 冰箱
- 我们目前没有时间处理的问题 接受贡献的时间。我们将关闭这些问题 虽然目前没人在处理这些内容,但会继续监控其 如果有足够多的人受到影响,或者我们恰好 处理它们的资源一如既往,即使问题已关闭,您也可以随时对其发表评论或添加回应。
团队标签
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
:用于编写规则/方面(提供程序、runfile、操作、工件)的 API- 联系人:comius
team-Rules-CPP
/team-Rules-ObjC
:C++/Objective-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: *
标签,由团队负责
标签。
如需查看完整标签列表,请点击此处。