Bazel 维护者指南

报告问题 查看源代码

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

如果您希望为 Bazel 贡献自己的力量，请改为参阅为 Bazel 贡献代码一文。

本页面的目的是：

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

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

  • 发布流程：管理 Bazel 的发布流程。
  • 绿色团队：发展一个由规则和工具组成的健康生态系统。
  • 开发者体验园丁：鼓励外部贡献、审核问题和拉取请求，并使我们的开发工作流更加开放。

版本

持续集成

在 bazelbuild/持续集成代码库中，阅读 Green 团队关于 Bazel 持续集成基础架构的指南。

问题的生命周期

  1. 用户通过选择其中一个问题模板来创建问题，然后进入未审核的待解决问题池。
  2. 开发者体验 (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: 标签，例如，针对 Mac 特有的问题分配一个 platform:apple。
  7. 如果问题优先级较低且可由新的社区贡献者处理，则 DevEx 成员会分配 good first issue 标签。在此阶段，问题会进入未分类的待解决问题池。

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

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

拉取请求的生命周期

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

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