本指南面向 Bazel 开源项目的维护者。
如果您想为 Bazel 贡献代码,请改为参阅为 Bazel 贡献代码。
本页旨在:
- 作为维护者在项目贡献过程中的可信来源。
- 为社区贡献者与项目维护者设定预期。
Bazel 的核心贡献者群组设有专门的子团队来管理开源项目的各个方面。具体包括:
- 发布流程:管理 Bazel 的发布流程。
- Green Team:推动由规则和工具组成的健康生态系统。
- 开发者体验园丁:鼓励外部贡献、审核问题和拉取请求,并让我们的开发工作流更加开放。
版本
持续集成
在 bazelbuild/Continuous-integration 代码库中阅读 Green 团队的指南,了解 Bazel 的 CI 基础架构。
问题的生命周期
- 用户通过选择一个问题模板来创建问题,系统会将问题进入到未审核的待解决的问题池中。
- 开发者体验 (DevEx) 子团队轮替中的一名成员将审核该问题。
- 如果问题不是 bug 或功能请求,DevEx 成员通常会关闭问题,并将用户重定向到 StackOverflow 和 bazel-discuss,以便更好地了解问题。
- 如果问题属于社区拥有的某个规则代码库(例如 rules_apple),则 DevEx 成员会将此问题转移到正确的代码库。
- 如果问题含糊不清或缺少信息,DevEx 成员会将问题重新分配给用户,要求用户提供更多信息,然后再继续。当用户没有选择正确的问题模板 {: .external} 或提供的信息不完整时,通常就会发生这种情况。
- 审核问题后,DevEx 成员决定是否需要立即关注该问题。如果是,他们将分配 P0 优先级标签,并从团队负责人列表中分配一位所有者。
- DevEx 成员为路由分配
untriaged
标签和仅一个团队标签。 - DevEx 成员还会根据问题类型仅分配一个
type:
标签,例如type: bug
或type: feature request
。 - 对于特定于平台的问题,DevEx 成员会分配一个
platform:
标签,例如为 Mac 特定问题分配platform:apple
标签。 - 如果问题的优先级较低,并且可由新的社区贡献者处理,则由 DevEx 成员分配
good first issue
标签。在此阶段,问题会进入未分类的待解决问题池。
每个 Bazel 子团队将根据其拥有的标签对所有问题进行分类,最好每周一次。子团队将审核和评估问题,并尽可能提供解决方案。如果您是团队标签的所有者,请参阅此部分 了解详情。
问题解决后,可以关闭。
拉取请求的生命周期
- 用户创建拉取请求。
- 如果您是 Bazel 团队的成员,并针对自己所在领域发送 PR,则需要负责分配团队标签并找到最佳审核者。
- 否则,在每日分类过程中,DevEx 成员会分配一个团队标签和团队的技术负责人 (TL) 来进行路由。
- 团队负责人 (TL) 可以选择指派其他人审核 PR。
- 指定的审核人员负责审核 PR,并与作者合作,直到 PR 被批准或放弃。
- 如果审核通过,审核者会将 PR 的提交内容导入 Google 的内部版本控制系统,以便进行进一步测试。由于 Bazel 是在 Google 内部使用的构建系统,因此我们需要针对内部测试套件测试所有 PR 提交。这就是我们不直接合并 PR 的原因。
- 如果导入的提交通过所有内部测试,则提交将被挤压并导出回 GitHub。
- 当提交内容合并到主实例时,GitHub 会自动关闭 PR。
我的团队拥有一个唱片公司。该怎么做?
子团队需要对其拥有的标签中的所有问题进行分类,最好每周进行一次。
问题
- 按团队标签和
untriaged
标签过滤问题列表。 - 查看问题。
- 确定优先级并分配标签。
- 如果是 P0 级问题,DevEx 子团队可能已优先处理该问题。根据需要重新确定优先级。
- 每个问题只能有一个优先级标签。如果问题为 P0 或 P1,我们假定问题已在积极解决。
- 移除
untriaged
标签。
请注意,您必须属于 bazelbuild 组织,才能添加或移除标签。
拉取请求
- 按团队标签过滤拉取请求列表。
- 查看待处理的拉取请求。
- 可选:如果您被指派负责审核,但审核人员并不适合,请重新指派适当的审核人员来执行代码审核。
- 与拉取请求创建者合作完成代码审核。
- 批准 PR。
- 确保通过所有测试。
- 将补丁导入到内部版本控制系统,并运行内部预提交。
- 提交内部补丁。如果补丁成功提交并导出,GitHub 将自动关闭 PR。
优先级
维护人员将使用以下优先级定义来对问题进行分类。
- P0 - 重大功能故障,导致 Bazel 版本(不含候选版本)不可用,或者服务已停用,严重影响 Bazel 项目的开发。这包括新版本中引入的导致大量用户阻塞的回归问题,或不符合重大更改政策的不兼容的破坏性更改。不存在实际的权宜解决方法。
- P1 - 应该在下一版本中解决的严重缺陷或功能,或者影响许多用户的严重问题(包括 Bazel 项目的开发),但有实际的权宜解决方法。通常不需要立即采取措施。需求量大,且已在本季度的路线图中规划。
- P2 - 应该解决但我们目前尚未开发的缺陷或功能。已发布的 Bazel 版本中存在中度实时问题,对于需要在未来的版本中解决的用户和/或有简单的权宜解决方法而言,该问题会给用户造成不便。
- P3 - 理想的次要 bug 修复或增强功能,影响很小。未优先纳入 Bazel 路线图或任何即将发布的版本,但鼓励社区贡献力量。
- P4 - 低优先级缺陷或不太可能关闭的功能请求。如果有更多用户受到影响,也可以保持开放状态,以便重新确定优先顺序。
- 冰箱
- 我们目前无法处理的问题,也没有时间接受贡献内容。我们将关闭这些问题,以表明目前无人在处理这些问题,但我们会继续监控这些问题的有效性,如果受影响的人员数量足够多,以及我们恰好有资源来处理这些问题,就会恢复这些问题。与往常一样,即使您关闭通知,也可以对这些问题发表评论或添加回应。
团队标签
team-Android
:Android 团队遇到的问题- 联系人:ahumesky
team-Bazel
:常规 Bazel 产品/策略问题- 联系人:sventiffe
team-CLI
:控制台界面- 联系人:meisterT
team-Configurability
:Configurability 团队遇到的问题。包括:核心 build 配置和转换系统。不包含:对新标志或现有标志的更改- 联系人:gregestren
team-Core
:Skyframe、bazel 查询、BEP、选项解析、bazelrc- 联系人:haxorz
team-Documentation
:文档团队遇到的问题- 联系人:philomathing
team-ExternalDeps
:外部依赖项处理、Bzlmod、远程仓库、WORKSPACE 文件- 联系人:meteorcloudy
team-Loading-API
:BUILD 文件和宏处理:标签、package()、可见性、glob- 联系人:brandjon
team-Local-Exec
:执行(本地)团队遇到的问题- 联系人:meisterT
team-OSS
:Bazel OSS 团队需要解决的问题:安装、发布流程、Bazel 打包、网站、文档基础架构- 联系人:meteorcloudy
team-Performance
:Bazel 性能团队遇到的问题- 联系人:meisterT
team-Remote-Exec
:执行(远程)团队遇到的问题- 联系人:coeuvre
team-Rules-API
:用于编写规则/方面(提供程序、runfile、操作、工件)的 API- 联系人:comius
team-Rules-CPP
/team-Rules-ObjC
:C++/Objective-C 规则(包括原生 Apple 规则逻辑)的问题- 联系人:oquenchil
team-Rules-Java
:Java 规则的问题- 联系人:hvadehra
team-Rules-Python
:原生 Python 规则的问题- 联系人:rickeylev
team-Rules-Server
:Bazel 随附的服务器端规则出现的问题- 联系人:comius
team-Starlark-Integration
:非 API Bazel + Starlark 集成。包括:Bazel 如何触发 Starlark 解释器、Stardoc、内置注入、字符编码。不包括:BUILD 或 .bzl 语言问题。- 联系人:brandjon
team-Starlark-Interpreter
:Starlark 解析器的问题(java.net.starlark 中的所有问题)。build 和 .bzl API 问题(代表 Bazel 与 Starlark 的集成)位于team-Build-Language
中。- 联系人:brandjon
对于新问题,我们废弃了 category: *
标签,取而代之的是团队标签。
请在此处查看完整的标签列表。