本指南面向的是 Bazel 开源项目的维护者。
如果您希望为 Bazel 贡献自己的力量,请改为参阅为 Bazel 贡献代码一文。
本页面的目的是:
- 充当项目贡献流程的维护者可信来源。
- 在社区贡献者和项目维护人员之间设定预期。
Bazel 的核心贡献者群组有专门的子团队来管理开源项目的各方面。它们是:
- 发布流程:管理 Bazel 的发布流程。
- 绿色团队:发展一个由规则和工具组成的健康生态系统。
- 开发者体验园丁:鼓励外部贡献、审核问题和拉取请求,并使我们的开发工作流更加开放。
版本
持续集成
在 bazelbuild/持续集成代码库中,阅读 Green 团队关于 Bazel 持续集成基础架构的指南。
问题的生命周期
- 用户通过选择其中一个问题模板来创建问题,然后进入未审核的待解决问题池。
- 开发者体验 (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) 来进行路由。
- 团队负责人可以选择指派其他人审核 PR。
- 分配的审核者审核 PR 并与作者合作,直到其获得批准或被丢弃。
- 如果批准,审核者会将 PR 的提交导入 Google 的内部版本控制系统,以进行进一步的测试。由于 Bazel 是 Google 在内部使用的构建系统,因此我们需要针对内部测试套件测试所有 PR 提交。正因如此,我们不直接合并 PR。
- 如果导入的提交通过所有内部测试,则该提交将被压缩,并将其导出回 GitHub。
- 当提交合并到 master 后,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 产品/策略问题- 联系人:meisterT
team-CLI
:控制台界面- 联系人:meisterT
team-Configurability
:需要配置团队遇到的问题。包括:核心 build 配置和转换系统。不包括:对新标志或现有标志的更改- 联系人:gregestren
team-Core
:Skyframe、bazel query、BEP、选项解析、bazelrc- 联系人:haxorz
team-Documentation
:文档团队遇到的问题team-ExternalDeps
:外部依赖项处理、Bzlmod、远程代码库、工作区文件- 联系人: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
:用于编写规则/方面的 API:提供程序、运行文件、操作、工件- 联系人:comius
team-Rules-CPP
/team-Rules-ObjC
:C++/Objective-C 规则的问题,包括原生 Apple 规则逻辑- 联系信息:buildbreaker2021
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: *
标签,改为使用团队标签。
如需查看完整的标签列表,请点击此处。