Bazel 维护者指南

报告问题 查看源代码 每夜版 · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

本指南面向 Bazel 开源项目的维护者。

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

本页面的目标是：

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

Bazel 的核心贡献者群组设有专门的子团队来管理开源项目的各个方面。它们是：

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

版本

持续集成

请访问 bazelbuild/continuous-integration 代码库，阅读 Green 团队关于 Bazel 的 CI 基础架构的指南。

问题的生命周期

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

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

问题解决后，可以将其关闭。

拉取请求的生命周期

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

我的团队拥有某个唱片公司。该怎么做？

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

问题

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

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

拉取请求

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

优先级

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

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

团队标签

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

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