Bazel 补丁接受流程Patch Acceptance Process全解析从提案到合入的完整路径【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel本篇技术指南系统讲解 Bazel 开源仓库的补丁接受流程Patch Acceptance Process外部贡献者如何从提出想法、撰写设计文档、签署 CLA到提交 Pull Request、完成代码评审直至补丁最终合入 master 的完整路径。读完本文你将掌握提交一个合规 Bazel 变更所需的全部前置条件、每一步的具体操作、评审与合入阶段的时间约定以及该流程背后先在 Google 内部版本控制系统验证、再导出回 GitHub这一特殊合入机制的成因。流程总览一次补丁提交的九个步骤Bazel 是一个由 Google 主导、拥有庞大外部贡献者社区的开源构建系统。由于 Bazel 同时也是 Google 内部使用的构建系统外部贡献的合入路径与普通开源项目评审后直接 merge的模式不同——所有外部补丁都要先导入 Google 内部版本控制系统通过内部预提交检查后再以 Git 提交的形式导出回 GitHub。docs/contribute/patch-acceptance.mdx 将完整流程概括为以下 9 个步骤阅读 Bazel 贡献政策创建 GitHub issue讨论你的计划与设计若是重大变更编写 设计文档签署 贡献者许可协议CLA准备实现功能的 git 提交含测试、文档必要时附 release notes在 GitHub 上创建 Pull Request由 Bazel maintainer 在 7 个工作日内指派 reviewer与 reviewer 协作完成代码评审评审通过后由 maintainer 将补丁应用至 Google 内部版本控制系统导出合入以下各节将按此顺序逐项展开。第 1 步理解贡献政策与角色分工流程的第一步是阅读 贡献政策。Bazel 项目由 Google 领导和管理采用三层角色模型Owners所有者即 Google Bazel 团队负责项目的战略、维护与领导构建和维护 Bazel 核心功能并任命 Maintainer、批准新仓库。Maintainers维护者Google Bazel 团队及被指定的 GitHub 用户负责维护其仓库的主要功能、评审与批准对应领域的贡献、以及时透明的方式支持用户与贡献者issue 管理、PR 评审、文档并参与发布、测试与协作。Contributors贡献者所有为 Bazel 贡献代码或文档的用户需要创建高质量的 PR并通过 GitHub Issues 等标准渠道提出变更与报告问题。贡献政策还明确了外部贡献的基本要求所有 Maintainers 与 Contributors 都必须签署 Google 的 Contributor License Agreement贡献应当写得良好、测试充分、经过相关领域 Maintainer 的讨论与批准并接入 Bazel 的持续集成系统。所有bazelbuild组织仓库的变更都必须经过评审——PR 需由 Owner 或 Maintainer 批准且只有 Owner 与 Maintainer 能合并 PR。第 2 步创建 GitHub Issue 跟踪变更在动手编码之前先在 bazelbuild/bazel 仓库创建一个 GitHub issue用于讨论计划与设计。任何改变或新增行为的 Pull Request 都必须有对应的 issue 用于跟踪。这条要求的价值在于让变更在早期就暴露给相关领域的维护者避免实现完成后才发现方向不对为后续的代码评审、release notes、以及合入记录提供可追踪的编号让社区其他用户能搜索到该变更的背景与迁移信息尤其是不兼容变更场景。从维护者一侧的视角看见 maintainers-guide.mdxissue 创建后会进入未分诊队列由 Developer ExperienceDevEx子团队的轮值成员评审非 bug/feature 类问题通常会被关闭并引导至 Stack Overflow 与 bazel-discuss属于社区规则仓库的问题会被转交transfer到对应仓库信息不完整的会被退回要求补充。随后 issue 会被打上untriaged标签、一个团队标签如team-Rules-Java、一个类型标签如type: bug以及可选的平台标签若适合新手参与还会被标记为good first issue。第 3 步重大变更需要设计文档如果提议的是重大变更必须编写设计文档并接受评审然后才能提交该变更。依据 设计文档政策需要设计评审的变更包括但不限于新增或删除原生构建规则native build rules对原生规则的不兼容变更影响多个规则语义的原生规则语义变更对 Bazel 规则定义 API 的变更Bazel 与其他系统对接 API 的变更对 Starlark 语言、语义或 API 的变更可能对 Bazel 性能或内存使用产生广泛影响的变更对广泛使用的内部 API 的变更对命令行标志flags与命令行接口的变更设计文档必须包含作者、最后重大修改日期、评审人列表其中必须且只能有一位 lead reviewer、当前状态draft / in review / approved / rejected / being implemented / implemented、讨论线程链接。有用户可见影响的提案必须包含向后兼容性影响说明。提案在邮件列表bazel-dev首次公告与最终批准之间必须间隔至少 1 周以保证用户有充足时间阅读并反馈。实现可以在提案获批前开始如作为概念验证但在评审完成前不能提交该变更。第 4 步签署贡献者许可协议CLA所有贡献者在提交代码前都必须签署 Google 的 Contributor License Agreement 特别说明CLA 通常只需要签署一次如果你之前为其他项目签署过即使是不同项目一般无需再次签署。第 5 步准备提交代码、测试、文档与 Release Notes实现功能时一次合格的提交应包含功能实现本身的代码变更测试——Bazel 仓库的测试分布在 src/test 下按语言划分src/test/java、src/test/shell、src/test/py、src/test/cpp等规则变更还需要接入 Bazel 的持续集成系统文档更新——如果变更影响用户可见行为需要同步更新文档由于 Bazel 文档是版本化的见 docs/versions 下的各版本目录文档变更不会意外提前发布。Release NotesRELNOTES 标签约定如果变更具有用户可见影响需要添加 release notes。依据 release-notes.mdxBazel 的提交描述中包含RELNOTES:标签Bazel 团队在每次发布时收集所有提交的 RELNOTES 标签来撰写发布公告。编写规范如下bugfix 不需要 release note但请在提交中引用对应 GitHub issue 编号release note 应简短理想情况下一句话、避免 Bazel 内部术语、聚焦变更本身包含指向相关文档的链接代码、符号、flag、含下划线的单词用反引号包裹一律使用现在时与统一句式Bazel now supports Y、X now does Z、X has been deprecated、X now $newBehavior instead of $oldBehavior解释变更/移除/废弃的原因一句话即可不要对未来功能做任何承诺避免 this flag will be removed 这类措辞。不兼容变更的额外要求如果变更属于不兼容变更须阅读 breaking-changes.mdx。Bazel 采用向后兼容策略不兼容变更需要走完整流程遵循设计文档政策 → 提交 GitHub issue → 实现 → 更新标签 → 更新下游仓库 → 翻转 flag。实现时的要点包括新 flag 默认值必须为false帮助文本须包含 issue 的 URL并带OptionMetadataTag.INCOMPATIBLE_CHANGE元数据标签提交描述中添加RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details将 flag 翻转为默认true时使用RELNOTES[INC]: ...并用Fixes #xyz关闭 issue计划在下一个大版本翻转的在 issue 上加breaking-change-X.0标签生态核心仓库通过 Bazel CI 的 BazelHEAD Downstream 管线测试需先迁移完成。第 6 步创建 Pull Request 与 Fork 工作流在 GitHub 创建 Pull Request。Bazel 主仓库限制创建分支的权限因此你需要将提交推送到自己的 fork再向主仓库发起 PR。需要强调的是从 PR 被创建的那一刻起Bazel 的 CI 就会接管验证。整个仓库根目录配置了完整的持续集成支撑MODULE.bazel、MODULE.bazel.lock、repositories.bzl、maven_install.json 等文件共同定义了依赖解析确保 PR 在标准化的环境下可复现构建。第 7 步指派 Reviewer 的时限约定创建 PR 后Bazel maintainer 应在7 个工作日不含美国和德国的节假日内为你指派 reviewer。如果在期限内未被指派你可以在 PR 上 bazelbuild/triage请求分诊。从维护者视角maintainers-guide.mdxPR 的流转逻辑是DevEx 成员在每日分诊中为 PR 指派一个团队标签与对应技术负责人TLTL 可以指定其他人评审每个 PR 期望在 7 个工作日内获得首次响应。评审期间 PR 会被打上awaiting-review、awaiting-user-response、awaiting-PR-merge等标签来标记状态。第 8 步与 Reviewer 协作完成代码评审评审阶段的操作规范针对评审意见为每个变更创建新的提交并推送到 PR而不是强制推送改写历史评审进度因此可追溯如果评审耗时过长例如 reviewer 长时间无响应可以在 PR 上 pingbazelbuild/triage所有bazelbuild仓库的变更都必须经过评审PR 须由 Owner 或 Maintainer 批准后才能合入。值得留意的是见 design-documents.mdx 的评审人工作流设计文档评审中使用的 LGTMLooks Good To Me惯例同样适用于一般代码评审语境。第 9 步内部导入、预提交检查与合入评审完成后最后一步由 Bazel maintainer 执行将你的补丁应用至 Google 内部版本控制系统。这会产生两个关键后果触发内部预提交检查由于 Bazel 本身就是 Google 内部使用的构建系统所有 PR 提交都必须通过内部测试套件验证见 maintainers-guide.mdx——这正是 Bazel 不直接 merge PR 的原因。检查可能提出更多修改建议如果你没有表达偏好提交变更的 maintainer 可能会添加不影响设计的 trivial 修改例如 lint如果需要更深入的修改、或你希望自己直接修改应在评审评论中与 reviewer 清楚沟通偏好导出回 GitHub 并关闭 PR内部提交通过后补丁会以 Git 提交形式导出此时 GitHub PR 自动关闭所有最终修改都归属于你。这也是为什么 patch-acceptance.mdx 反复强调沟通偏好的原因——内部检查阶段由 maintainer 代为落地的改动与你在 GitHub 上直接修改的效果在合入路径上是不同的。合入之后issue 与 PR 的生命周期闭环理解补丁接受流程还需要从维护者的视角看清合入后整个工单系统的闭环逻辑PR 关闭内部提交通过全部测试后被 squash 并导出回 GitHub合入 master 时 GitHub 自动关闭 PR见 maintainers-guide.mdx不合规 PR 的关闭如果 PR 与 Bazel 目标不符、过大过复杂、代码质量不达标、或未来维护成本过高维护者会礼貌关闭并解释原因等待用户响应超过 30 天的 PR 会被自动标记为 stale再过 30 天关闭issue 的关闭issue 经团队分诊、打优先级标签P0–P4后由对应子团队按周分诊处理解决后关闭。优先级定义可查阅 maintainers-guide.mdx。小结Bazel 的补丁接受流程可以概括为一条主线issue 讨论 →重大变更设计评审 → CLA → 实现并提交 → PR 评审 → 内部导入验证 → 导出合入。对贡献者而言最需要注意的三个特殊点是所有行为变更必须有对应 issueBazel 不直接合并 PR而是经由 Google 内部版本控制系统的双重验证以及 7 个工作日响应、内部 trivial 修改归属等具体约定。把每一步做对你的补丁就能沿着这条经过大量验证的路径顺利进入 Bazel。【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Bazel 补丁接受流程（Patch Acceptance Process）全解析：从提案到合入的完整路径
Bazel 补丁接受流程Patch Acceptance Process全解析从提案到合入的完整路径【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel本篇技术指南系统讲解 Bazel 开源仓库的补丁接受流程Patch Acceptance Process外部贡献者如何从提出想法、撰写设计文档、签署 CLA到提交 Pull Request、完成代码评审直至补丁最终合入 master 的完整路径。读完本文你将掌握提交一个合规 Bazel 变更所需的全部前置条件、每一步的具体操作、评审与合入阶段的时间约定以及该流程背后先在 Google 内部版本控制系统验证、再导出回 GitHub这一特殊合入机制的成因。流程总览一次补丁提交的九个步骤Bazel 是一个由 Google 主导、拥有庞大外部贡献者社区的开源构建系统。由于 Bazel 同时也是 Google 内部使用的构建系统外部贡献的合入路径与普通开源项目评审后直接 merge的模式不同——所有外部补丁都要先导入 Google 内部版本控制系统通过内部预提交检查后再以 Git 提交的形式导出回 GitHub。docs/contribute/patch-acceptance.mdx 将完整流程概括为以下 9 个步骤阅读 Bazel 贡献政策创建 GitHub issue讨论你的计划与设计若是重大变更编写 设计文档签署 贡献者许可协议CLA准备实现功能的 git 提交含测试、文档必要时附 release notes在 GitHub 上创建 Pull Request由 Bazel maintainer 在 7 个工作日内指派 reviewer与 reviewer 协作完成代码评审评审通过后由 maintainer 将补丁应用至 Google 内部版本控制系统导出合入以下各节将按此顺序逐项展开。第 1 步理解贡献政策与角色分工流程的第一步是阅读 贡献政策。Bazel 项目由 Google 领导和管理采用三层角色模型Owners所有者即 Google Bazel 团队负责项目的战略、维护与领导构建和维护 Bazel 核心功能并任命 Maintainer、批准新仓库。Maintainers维护者Google Bazel 团队及被指定的 GitHub 用户负责维护其仓库的主要功能、评审与批准对应领域的贡献、以及时透明的方式支持用户与贡献者issue 管理、PR 评审、文档并参与发布、测试与协作。Contributors贡献者所有为 Bazel 贡献代码或文档的用户需要创建高质量的 PR并通过 GitHub Issues 等标准渠道提出变更与报告问题。贡献政策还明确了外部贡献的基本要求所有 Maintainers 与 Contributors 都必须签署 Google 的 Contributor License Agreement贡献应当写得良好、测试充分、经过相关领域 Maintainer 的讨论与批准并接入 Bazel 的持续集成系统。所有bazelbuild组织仓库的变更都必须经过评审——PR 需由 Owner 或 Maintainer 批准且只有 Owner 与 Maintainer 能合并 PR。第 2 步创建 GitHub Issue 跟踪变更在动手编码之前先在 bazelbuild/bazel 仓库创建一个 GitHub issue用于讨论计划与设计。任何改变或新增行为的 Pull Request 都必须有对应的 issue 用于跟踪。这条要求的价值在于让变更在早期就暴露给相关领域的维护者避免实现完成后才发现方向不对为后续的代码评审、release notes、以及合入记录提供可追踪的编号让社区其他用户能搜索到该变更的背景与迁移信息尤其是不兼容变更场景。从维护者一侧的视角看见 maintainers-guide.mdxissue 创建后会进入未分诊队列由 Developer ExperienceDevEx子团队的轮值成员评审非 bug/feature 类问题通常会被关闭并引导至 Stack Overflow 与 bazel-discuss属于社区规则仓库的问题会被转交transfer到对应仓库信息不完整的会被退回要求补充。随后 issue 会被打上untriaged标签、一个团队标签如team-Rules-Java、一个类型标签如type: bug以及可选的平台标签若适合新手参与还会被标记为good first issue。第 3 步重大变更需要设计文档如果提议的是重大变更必须编写设计文档并接受评审然后才能提交该变更。依据 设计文档政策需要设计评审的变更包括但不限于新增或删除原生构建规则native build rules对原生规则的不兼容变更影响多个规则语义的原生规则语义变更对 Bazel 规则定义 API 的变更Bazel 与其他系统对接 API 的变更对 Starlark 语言、语义或 API 的变更可能对 Bazel 性能或内存使用产生广泛影响的变更对广泛使用的内部 API 的变更对命令行标志flags与命令行接口的变更设计文档必须包含作者、最后重大修改日期、评审人列表其中必须且只能有一位 lead reviewer、当前状态draft / in review / approved / rejected / being implemented / implemented、讨论线程链接。有用户可见影响的提案必须包含向后兼容性影响说明。提案在邮件列表bazel-dev首次公告与最终批准之间必须间隔至少 1 周以保证用户有充足时间阅读并反馈。实现可以在提案获批前开始如作为概念验证但在评审完成前不能提交该变更。第 4 步签署贡献者许可协议CLA所有贡献者在提交代码前都必须签署 Google 的 Contributor License Agreement 特别说明CLA 通常只需要签署一次如果你之前为其他项目签署过即使是不同项目一般无需再次签署。第 5 步准备提交代码、测试、文档与 Release Notes实现功能时一次合格的提交应包含功能实现本身的代码变更测试——Bazel 仓库的测试分布在 src/test 下按语言划分src/test/java、src/test/shell、src/test/py、src/test/cpp等规则变更还需要接入 Bazel 的持续集成系统文档更新——如果变更影响用户可见行为需要同步更新文档由于 Bazel 文档是版本化的见 docs/versions 下的各版本目录文档变更不会意外提前发布。Release NotesRELNOTES 标签约定如果变更具有用户可见影响需要添加 release notes。依据 release-notes.mdxBazel 的提交描述中包含RELNOTES:标签Bazel 团队在每次发布时收集所有提交的 RELNOTES 标签来撰写发布公告。编写规范如下bugfix 不需要 release note但请在提交中引用对应 GitHub issue 编号release note 应简短理想情况下一句话、避免 Bazel 内部术语、聚焦变更本身包含指向相关文档的链接代码、符号、flag、含下划线的单词用反引号包裹一律使用现在时与统一句式Bazel now supports Y、X now does Z、X has been deprecated、X now $newBehavior instead of $oldBehavior解释变更/移除/废弃的原因一句话即可不要对未来功能做任何承诺避免 this flag will be removed 这类措辞。不兼容变更的额外要求如果变更属于不兼容变更须阅读 breaking-changes.mdx。Bazel 采用向后兼容策略不兼容变更需要走完整流程遵循设计文档政策 → 提交 GitHub issue → 实现 → 更新标签 → 更新下游仓库 → 翻转 flag。实现时的要点包括新 flag 默认值必须为false帮助文本须包含 issue 的 URL并带OptionMetadataTag.INCOMPATIBLE_CHANGE元数据标签提交描述中添加RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details将 flag 翻转为默认true时使用RELNOTES[INC]: ...并用Fixes #xyz关闭 issue计划在下一个大版本翻转的在 issue 上加breaking-change-X.0标签生态核心仓库通过 Bazel CI 的 BazelHEAD Downstream 管线测试需先迁移完成。第 6 步创建 Pull Request 与 Fork 工作流在 GitHub 创建 Pull Request。Bazel 主仓库限制创建分支的权限因此你需要将提交推送到自己的 fork再向主仓库发起 PR。需要强调的是从 PR 被创建的那一刻起Bazel 的 CI 就会接管验证。整个仓库根目录配置了完整的持续集成支撑MODULE.bazel、MODULE.bazel.lock、repositories.bzl、maven_install.json 等文件共同定义了依赖解析确保 PR 在标准化的环境下可复现构建。第 7 步指派 Reviewer 的时限约定创建 PR 后Bazel maintainer 应在7 个工作日不含美国和德国的节假日内为你指派 reviewer。如果在期限内未被指派你可以在 PR 上 bazelbuild/triage请求分诊。从维护者视角maintainers-guide.mdxPR 的流转逻辑是DevEx 成员在每日分诊中为 PR 指派一个团队标签与对应技术负责人TLTL 可以指定其他人评审每个 PR 期望在 7 个工作日内获得首次响应。评审期间 PR 会被打上awaiting-review、awaiting-user-response、awaiting-PR-merge等标签来标记状态。第 8 步与 Reviewer 协作完成代码评审评审阶段的操作规范针对评审意见为每个变更创建新的提交并推送到 PR而不是强制推送改写历史评审进度因此可追溯如果评审耗时过长例如 reviewer 长时间无响应可以在 PR 上 pingbazelbuild/triage所有bazelbuild仓库的变更都必须经过评审PR 须由 Owner 或 Maintainer 批准后才能合入。值得留意的是见 design-documents.mdx 的评审人工作流设计文档评审中使用的 LGTMLooks Good To Me惯例同样适用于一般代码评审语境。第 9 步内部导入、预提交检查与合入评审完成后最后一步由 Bazel maintainer 执行将你的补丁应用至 Google 内部版本控制系统。这会产生两个关键后果触发内部预提交检查由于 Bazel 本身就是 Google 内部使用的构建系统所有 PR 提交都必须通过内部测试套件验证见 maintainers-guide.mdx——这正是 Bazel 不直接 merge PR 的原因。检查可能提出更多修改建议如果你没有表达偏好提交变更的 maintainer 可能会添加不影响设计的 trivial 修改例如 lint如果需要更深入的修改、或你希望自己直接修改应在评审评论中与 reviewer 清楚沟通偏好导出回 GitHub 并关闭 PR内部提交通过后补丁会以 Git 提交形式导出此时 GitHub PR 自动关闭所有最终修改都归属于你。这也是为什么 patch-acceptance.mdx 反复强调沟通偏好的原因——内部检查阶段由 maintainer 代为落地的改动与你在 GitHub 上直接修改的效果在合入路径上是不同的。合入之后issue 与 PR 的生命周期闭环理解补丁接受流程还需要从维护者的视角看清合入后整个工单系统的闭环逻辑PR 关闭内部提交通过全部测试后被 squash 并导出回 GitHub合入 master 时 GitHub 自动关闭 PR见 maintainers-guide.mdx不合规 PR 的关闭如果 PR 与 Bazel 目标不符、过大过复杂、代码质量不达标、或未来维护成本过高维护者会礼貌关闭并解释原因等待用户响应超过 30 天的 PR 会被自动标记为 stale再过 30 天关闭issue 的关闭issue 经团队分诊、打优先级标签P0–P4后由对应子团队按周分诊处理解决后关闭。优先级定义可查阅 maintainers-guide.mdx。小结Bazel 的补丁接受流程可以概括为一条主线issue 讨论 →重大变更设计评审 → CLA → 实现并提交 → PR 评审 → 内部导入验证 → 导出合入。对贡献者而言最需要注意的三个特殊点是所有行为变更必须有对应 issueBazel 不直接合并 PR而是经由 Google 内部版本控制系统的双重验证以及 7 个工作日响应、内部 trivial 修改归属等具体约定。把每一步做对你的补丁就能沿着这条经过大量验证的路径顺利进入 Bazel。【免费下载链接】bazela fast, scalable, multi-language and extensible build system项目地址: https://gitcode.com/GitHub_Trending/ba/bazel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考