相约 2023 年 BazelCon 将于 10 月 24 日至 25 日在 Google 慕尼黑举办!了解详情

Bazel 维护者指南

报告问题 查看源代码

本指南适用于 Bazel 开源项目的维护人员。

如果您希望为 Bazel 做贡献,请参阅为 Bazel 做贡献

本页旨在:

  1. 充当项目的贡献流程的维护者可信来源。
  2. 在社区贡献者与项目维护者之间设定预期。

Bazel 的贡献者核心组拥有专门的子团队来管理该开源项目的方方面面。这些国家/地区包括:

  • 发布流程:管理 Bazel 的发布流程。
  • 绿色团队:打造一个健康规则和工具生态系统,
  • 开发者体验园丁:鼓励外部人员贡献内容,审核问题并拉取请求,使我们的开发工作流更开放。

版本

持续集成

阅读针对 bazelbuild/持续集成代码库上的 Bazel CI 基础架构的绿色团队指南。

问题的生命周期

  1. 用户使用问题模板创建了问题,此时问题进入了未审核的待解决问题池。
  2. 开发者体验 (DevEx) 子团队轮替的成员正在审核问题。
    1. 如果问题不是 bug功能请求,DevEx 成员通常会关闭问题并将用户重定向到 StackOverflowbazel-discuss,以提高问题的可见性。
    2. 如果问题属于社区拥有的某个规则代码库(如 rules_apple),DevEx 成员将将此问题转移到正确的代码库。
    3. 如果问题含糊不清或缺少信息,DevEx 成员会将问题分配回用户,要求提供更多信息后再继续。通常,如果用户未遵循问题模板,就会出现这种情况。
  3. 审核问题后,DevEx 成员会决定是否需要立即关注问题。如果存在这种情况,他们将分配 P0 优先级标签以及团队负责人列表中的所有者。
  4. DevEx 成员会为路由分配 untriaged 标签和仅一个团队标签
  5. DevEx 成员还会根据问题类型分配一个 type: 标签,例如 type: bugtype: feature request
  6. 对于平台特有的问题,DevEx 成员会分配一个 platform: 标签,例如 Mac 特有的问题对应的 platform:apple
  7. 如果问题优先级较低且可由新的社区贡献者处理,DevEx 成员会分配 good first issue 标签。在此阶段,问题会进入未分类的待解决问题池。

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

问题解决后,便可将其关闭。

拉取请求的生命周期

  1. 用户创建拉取请求。
  2. 如果您是 Bazel 团队的成员,并在自己的领域发送 PR,则需自行分配您的团队标签并寻找最佳审核者。
  3. 否则,在日常分类中,DevEx 成员会分配一个团队标签和团队的技术主管 (TL) 进行路由。
    1. 团队负责人可以选择指定其他人来查看公共关系。
  4. 已分配的审核人员会审核 PR,并与作者合作,直到其获得批准或被弃用。
  5. 如果获得批准,审核人员会将 PR 的提交导入 Google 的内部版本控制系统,以供进一步测试。由于 Bazel 与 Google 在内部使用的构建系统相同,我们需要针对内部测试套件测试所有 PR 提交。正因如此,我们不会直接合并 PR。
  6. 如果导入的提交通过所有内部测试,则系统将压缩该提交并将其导出回 GitHub。
  7. 当提交合并到主实例时,GitHub 会自动关闭 PR。

我的团队拥有标签。该怎么做?

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

问题

  1. 按您的团队标签和 untriaged 标签过滤问题列表。
  2. 查看问题。
  3. 确定优先级并分配标签。
    1. 如果 DevEx 子团队是 P0,则问题可能已优先处理。如有需要,请重新确定优先顺序。
    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 - 低优先级缺陷或不太可能被关闭的功能请求。如果受影响的用户较多,也可以保持开放以便重新确定优先级。
  • ice-box
    • 我们目前没有时间处理的问题,也没有时间接受贡献内容。我们会关闭这些问题,以指出没有人处理这些问题,但随着时间推移,如果有足够多的人受到影响,并且我们恰好有资源可以处理,我们将继续监控其有效性,并使其恢复有效。与往常一样,即使关闭该页面,您也可以添加评论或回应。

团队标签

对于新问题,我们弃用了 category: * 标签,取而代之的是团队标签。

如需查看完整的标签列表,请点击此处