Bazel 维护者指南

<ph type="x-smartling-placeholder"></ph> 报告问题 查看来源 敬上 每晚 · 7.3。 · 7.2。 · 7.1。 · 7.0。 · 6.5

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

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

本页旨在：

  1. 作为维护者项目贡献的可信来源 过程。
  2. 为社区贡献者和项目设定预期 维护者。

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

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

版本

持续集成

阅读绿色团队关于 Bazel 持续集成基础架构的指南， bazelbuild/continuous-integration 存储库

问题的生命周期

  1. 用户通过选择 问题模板 然后进入未审核的待处理 问题。
  2. 开发者体验 (DevEx) 子团队轮流中的一名成员负责审核 问题。
    1. 如果问题不是错误或功能请求，DevEx 成员 通常会关闭问题并将用户重定向到 StackOverflow 和 bazel-COMMENT 以便提高问题的曝光度
    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 团队的成员，并针对自己所在领域发送公关请求 您负责为您的团队分配标签，并找出 审核员。
  3. 否则，在每日分类过程中，DevEx 成员会分配一个 团队标签和移交团队的技术主管 (TL)。
    1. 团队负责人 (TL) 可以选择指派其他人审核 PR。
  4. 指定的审核人员审核 PR 并与作者合作，直到完成 批准或舍弃。
  5. 如果审核通过，审核人员会将 PR 的提交导入 Google 的 以便进一步测试由于 Bazel 是相同的 build Google 内部使用的系统，我们需要根据 内部测试套件这就是我们不直接合并 PR 的原因。
  6. 如果导入的提交内容通过了所有内部测试，则提交内容将被撤消 并将其导出回 GitHub。
  7. 当提交内容合并到主实例时，GitHub 会自动关闭 PR。

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

子团队需要对他们拥有的标签中的所有问题进行分类， 最好每周更新一次

问题

  1. 按团队标签和 untriaged 标签过滤问题列表。
  2. 查看问题。
  3. 确定优先级并分配标签。
    1. 如果此问题属于 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 - 低优先级缺陷 或功能请求。也可以保持打开状态 如果有更多用户受到影响，您可能需要重新优先处理这些问题。
  • 冰箱
    • 我们目前没有时间处理的问题 接受贡献的时间。我们将关闭这些问题 虽然目前没人在处理这些内容，但会继续监控其 如果有足够多的人受到影响，或者我们恰好 处理它们的资源与往常一样，随时发表评论或添加回应 以解决此类问题。

团队标签

对于新问题，我们废弃了 category: * 标签，由团队负责 标签。

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