Bazel 维护者指南

报告问题 查看源代码

本指南面向 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 标签和仅一个团队标签。
  5. DevEx 成员还会根据问题类型仅分配一个 type: 标签，例如 type: bug 或 type: feature request。
  6. 对于特定于平台的问题，DevEx 成员会分配一个 platform: 标签，例如为 Mac 特定问题分配 platform:apple 标签。在此阶段，问题会进入未分类的待解决问题池。

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

问题解决后，可以关闭。

拉取请求的生命周期

  1. 用户创建拉取请求。
  2. 如果您是 Bazel 团队的成员，并针对自己所在领域发送 PR，则需要负责分配团队标签并找到最佳审核者。
  3. 否则，在每日分类过程中，DevEx 成员会分配一个团队标签和团队的技术负责人 (TL) 来进行路由。
    1. 团队负责人 (TL) 可以选择指派其他人审核 PR。
  4. 指定的审核人员负责审核 PR，并与作者合作，直到 PR 被批准或放弃。
  5. 如果审核通过，审核者会将 PR 的提交内容导入 Google 的内部版本控制系统，以便进行进一步测试。由于 Bazel 是在 Google 内部使用的构建系统，因此我们需要针对内部测试套件测试所有 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: * 标签，取而代之的是团队标签。

请在此处查看完整的标签列表。