Bazel 维护者指南

这是 Bazel 开源项目的维护者的指南。

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

本页面旨在:

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

Bazel' 贡献者核心组拥有专门的子团队来管理开源项目的各方面。这些概念包括:

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

版本

持续集成

阅读 Green 团队发布的 bazelbuild/持续集成代码库中的 Bazel&CI 基础架构基础架构指南。

问题的生命周期

  1. 用户使用问题模板创建问题,并进入未审核的待解决的问题池。
  2. 开发者体验 (DevEx) 子团队轮替的成员会审核此问题。
    1. 如果问题不是错误功能请求,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。在此阶段,问题进入未分类的待解决问题池。

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

问题解决后,系统会将其关闭。

拉取请求的生命周期

  1. 用户创建拉取请求。
  2. 如果您是 Bazel 团队成员,并且负责发送针对您所在区域的 PR,则需负责分配您的团队标签并寻找最佳审核者。
  3. 否则,在每日分类期间,DevEx 成员会分配一个团队标签以及团队的技术主管 (TL) 进行路由。
    1. 团队负责人可以选择指派其他人审核此 PR。
  4. 指定的审核人员会审核 PR,并与作者合作,直到 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 - 修正了次要错误,或进行了轻微的改进,但影响较小。没有优先考虑到 Bazel 路线图或任何即将推出的版本中,但我们鼓励社区贡献代码。
  • P4 - 不太可能导致低优先级缺陷或功能请求。如果有更多用户受到影响,您还可以使应用保持打开状态,以便重新确定其优先级。
  • ice-box
    • 我们目前没有时间处理的问题,也没有时间接受贡献的内容。我们会关闭这些问题,以指出没有人在努力处理这些问题,但我们会继续监控这些功能的有效性,并在有足够多的人受到影响以及我们恰好有资源可以处理时,再解决这些问题。与往常一样,即使这些问题已经解决,您也随时可以发表评论或添加回应。

团队标签

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

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