Bazel 维护者指南

Nightly · 9.1 · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

本文档是为 Bazel 开源项目的维护人员编写的指南。

如果您想为 Bazel 做贡献，请改为阅读为 Bazel 做贡献。

本页面的目标是：

  1. 作为维护人员了解项目贡献流程的可信来源。
  2. 在社区贡献者和项目维护人员之间设定预期。

Bazel 的 核心贡献者团队 设有专门的 子团队来管理开源项目的各个方面。这些子团队包括：

  • 发布流程：管理 Bazel 的发布流程。
  • Green Team：打造健康的规则和工具生态系统。
  • Developer Experience Gardeners：鼓励外部贡献，审核 问题和拉取请求，并让我们的开发工作流程更加开放。

版本

持续集成

如需了解 Bazel 的持续集成基础架构，请参阅 Green Team 的指南，该指南位于 bazelbuild/continuous-integration 代码库中。

问题的生命周期

  1. 用户使用问题 模板 创建问题，该问题会进入待审核的未解决 问题池。
  2. Developer Experience (DevEx) 子团队轮换成员审核该问题。
    1. 如果该问题不是 bug 或功能请求，DevEx 成员 通常会关闭该问题，并将用户重定向到 StackOverflow 和 bazel-discuss，以便用户的问题获得 更高的曝光度。
    2. 如果该问题属于社区拥有的某个规则代码库（例如 rules_apple），DevEx 成员会将该问题转移到正确的代码库。
    3. 如果该问题不明确或缺少信息，DevEx 成员会将该问题重新分配给用户，要求用户提供更多信息，然后再继续。这种情况通常发生在用户未遵循问题 模板时。
  3. 审核问题后，DevEx 成员会决定该问题是否需要立即处理。如果需要，他们会分配 P0 优先级 标签，并从团队负责人列表中分配负责人。
  4. DevEx 成员会分配 untriaged 标签，并分配一个 团队 标签 以进行路由。
  5. DevEx 成员还会根据问题的类型分配一个 type: 标签，例如 type: bug 或 type: feature request。
  6. 对于特定于平台的问题，DevEx 成员会分配一个 platform: 标签， 例如针对 Mac 特定问题的 platform:apple。 在此阶段，该问题会进入待分诊的未解决 问题池。

每个 Bazel 子团队都会对他们拥有的标签下的所有问题进行分诊，最好每周一次。子团队将审核和评估问题，并尽可能提供解决方案。如果您是团队标签的所有者，请参阅此部分 了解详情。

问题解决后，可以关闭。

拉取请求的生命周期

  1. 用户创建拉取请求。
  2. 如果您是 Bazel 团队的成员，并且要针对自己的领域发送拉取请求，则您有责任分配团队标签并找到最佳审核者。
  3. 否则，在每日分诊期间，DevEx 成员会分配一个 团队标签和团队的技术负责人 (TL) 以进行路由。
    1. TL 可以选择分配其他人来审核拉取请求。
  4. 分配的审核者会审核拉取请求，并与作者协作，直到拉取请求获得批准或被放弃。
  5. 如果获得批准，审核者会将拉取请求的提交内容导入 Google 的内部版本控制系统以进行进一步测试。由于 Bazel 是 Google 内部使用的构建系统，因此我们需要针对内部测试套件测试所有拉取请求提交内容。这就是我们不直接合并拉取请求的原因。
  6. 如果导入的提交内容通过了所有内部测试，则该提交内容将被压缩并导出回 GitHub。
  7. 当提交内容合并到主分支时，GitHub 会自动关闭拉取请求。

我的团队拥有一个标签。该怎么做？

子团队需要对他们拥有的标签中的所有问题进行分诊， 最好每周一次。

问题

  1. 按您的团队标签和 untriaged 标签过滤问题列表。
  2. 查看问题。
  3. 确定优先级并分配标签。
    1. 如果问题是 P0，DevEx 子团队可能已确定其优先级。请根据需要重新确定优先级。
    2. 每个问题都需要恰好有一个优先级标签。如果问题是 P0 或 P1，我们假设该问题正在积极处理中。
  4. 移除 untriaged 标签。

请注意，您需要加入 bazelbuild 组织 才能添加或移除标签。

拉取请求

  1. 按您的团队标签过滤拉取请求列表。
  2. 审核未解决的拉取请求。
    1. 可选：如果您被分配进行审核，但并不适合 审核，请重新分配合适的审核者来执行代码审核。
  3. 与拉取请求创建者协作完成代码审核。
  4. 批准拉取请求。
  5. 确保所有测试均通过。
  6. 将补丁导入内部版本控制系统并运行内部预提交。
  7. 提交内部补丁。如果补丁提交和导出成功，GitHub 会自动关闭拉取请求。

优先级

维护人员将使用以下优先级定义来分诊问题。

  • P0 - 导致 Bazel 版本（不包括候选版本）无法使用的主要功能损坏，或严重影响 Bazel 项目开发的停机服务。这包括新版本中引入的回归，这些回归会阻止大量用户，或者不兼容的重大更改不符合重大 更改 政策。没有可行的变通方案。
  • P1 - 应在下一个版本中解决的关键缺陷或 功能，或影响许多用户（包括 Bazel 项目的开发）的严重问题，但存在 可行的变通方案。通常不需要立即采取行动。需求量大，并计划在当前季度的路线图中。
  • P2 - 应解决但我们目前未处理的缺陷或功能。已发布的 Bazel 版本中存在中度投放问题，给需要解决该问题的用户造成不便，并且/或者存在简单的变通方案。
  • P3 - 影响较小的理想小 bug 修复或增强功能。未优先纳入 Bazel 路线图或任何即将发布的版本，但鼓励社区贡献。
  • P4 - 不太可能关闭的低优先级缺陷 或功能请求。如果更多用户受到影响，也可以保持未解决状态，以便重新确定优先级。
  • ice-box
    • 我们目前没有时间处理或接受贡献的问题。我们将关闭这些问题，以表明没有人正在处理这些问题，但会随着时间的推移继续监控其有效性，并在足够多的人受到影响且我们有资源处理这些问题时恢复这些问题。与往常一样，即使这些问题已关闭，您也可以随时评论或添加反应。

团队标签

对于新问题，我们已弃用 category: * 标签，改用团队标签。

点击此处查看完整标签列表。