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 的 CI 基础架构，请参阅 bazelbuild/continuous-integration 代码库中的 Green Team 指南。

问题的生命周期

  1. 用户选择一个 问题模板来创建问题，然后该问题会进入未审核的开放 问题池。
  2. Developer Experience (DevEx) 子团队轮换成员审核该问题。
    1. 如果该问题不是 bug 或功能请求，DevEx 成员通常会关闭该问题，并将用户重定向到StackOverflow 和bazel-discuss，以便用户更轻松地找到问题的答案。
    2. 如果该问题属于社区拥有的某个规则代码库（例如 rules_apple），DevEx 成员会将该问题转移到正确的代码库。
    3. 如果问题模糊不清或缺少信息，DevEx 成员会将问题重新分配给用户，要求用户提供更多信息，然后再继续。如果用户未选择正确的 问题模板 {: .external} 或提供的信息不完整，通常会发生这种情况。
  3. 审核问题后，DevEx 成员会决定该问题是否需要立即处理。如果需要，他们会分配 P0 优先级 标签，并从团队负责人列表中分配负责人。
  4. DevEx 成员会分配 untriaged 标签，并分配一个 团队 标签 以进行路由。
  5. DevEx 成员还会根据问题的类型分配一个 type: 标签，例如 type: bug 或 type: feature request。
  6. 对于特定于平台的问题，DevEx 成员会分配一个 platform: 标签， 例如 platform:apple 针对特定于 Mac 的问题。
  7. 如果问题优先级较低，并且可以由新的社区贡献者处理，DevEx 成员会分配 good first issue 标签。 在此阶段，问题会进入未分类的开放 问题池。

每个 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: * 标签，改用团队标签。

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