本文已超过一年。旧文章可能包含过时内容。请检查页面信息自发布以来是否已不再准确。
SIG Architecture 聚焦：代码组织
这是 SIG Architecture 聚焦系列采访的第三篇，该系列将涵盖不同的子项目。我们将介绍SIG Architecture：代码组织。
在本篇 SIG Architecture 聚焦文章中，我采访了代码组织子项目成员Madhav Jivrajani (VMware)。
介绍代码组织子项目
Frederico (FSM): 你好 Madhav，感谢你抽出时间。你能否先简单介绍一下你自己、你的角色以及你是如何参与到 Kubernetes 项目中的？
Madhav Jivrajani (MJ): 你好！我的名字是 Madhav Jivrajani，我担任 SIG Contributor Experience 的技术负责人以及 Kubernetes 项目的 GitHub 管理员。除此之外，我也为 SIG API Machinery 和 SIG Etcd 做出贡献，但最近，我主要协助完成帮助 Kubernetes 保持在支持的 Go 版本上所需的工作，我也是通过这项工作参与到 SIG Architecture 的代码组织子项目中的。
FSM: 对于像 Kubernetes 这么大规模的项目来说，代码组织方面肯定面临着独特的挑战——这个假设是否合理？如果是，你认为哪些是 Kubernetes 特有的主要挑战？
MJ: 这个假设很合理！第一个有趣的挑战来自于 Kubernetes 代码库的庞大规模。我们有大约 220 万行 Go 代码（得益于dims 和这个子项目中的其他贡献者，这个数字正在稳步下降！），以及直接或间接依赖的 240 多个依赖项，这就是为什么设立一个专门的子项目来协助处理依赖项管理至关重要：我们需要知道我们引入了哪些依赖项，这些依赖项的版本是什么，以及确保我们在代码库不同部分以一致的方式管理这些依赖项的工具。
Kubernetes 的另一个有趣的挑战是，我们在 Kubernetes 发布周期中发布了许多 Go 模块，例如client-go。然而，作为项目，我们也希望将所有内容放在一个仓库中，以获得使用单仓库（monorepo）的优势，比如原子提交（atomic commits）……因此，代码组织与其他 SIG（例如 SIG Release）合作，自动化地将代码从单仓库发布到下游的各个独立仓库，这些仓库更容易被使用，这样您就不必导入整个 Kubernetes 代码库了！
代码组织与 Kubernetes
FSM: 对于刚开始从代码层面为 Kubernetes 做出贡献的人来说，他们在代码组织方面应该考虑哪些主要事项？你如何总结关键概念？
MJ: 我认为对于刚开始贡献的人来说，需要记住的一个关键概念是 staging 目录。在kubernetes/kubernetes 仓库中，你会看到一个名为staging/ 的目录。这个目录下的子文件夹充当着一组伪仓库。例如，发布 client-go 版本的kubernetes/client-go 仓库实际上是一个staging repo。
FSM: 那么 staging 目录的概念是否根本上影响了贡献方式？
MJ: 正是如此，因为如果你想为任何 staging 仓库贡献代码，你需要向 kubernetes/kubernetes 中对应的 staging 目录提交一个 PR。一旦代码合并到那里，我们有一个名为publishing-bot 的机器人会自动将合并后的提交同步到所需的 staging 仓库（如 kubernetes/client-go）。这样，我们既获得了单仓库的好处，又可以模块化地发布代码供下游使用。附注：publishing-bot 需要更多人来帮忙！
有关 staging 仓库的更多信息，请参阅贡献者文档。
FSM: 谈到贡献，贡献者数量众多，包括个人和公司，这肯定也是一个挑战：子项目如何确保遵守标准？
MJ: 关于项目的依赖项管理，有一个专门的团队负责审查和批准依赖项的变更。这些贡献者帮助奠定了 Kubernetes 今天用于依赖项管理的许多工具的基础。这些工具确保贡献者可以以一致的方式对依赖项进行更改。项目还开发了额外的工具来显示新增或删除依赖项的统计信息：depstat。
除了依赖项管理之外，项目的另一个关键任务是管理 staging 仓库。实现此目的的工具（publishing-bot）对贡献者是完全透明的，并有助于确保 staging 仓库获得提交到 kubernetes/kubernetes 的贡献的统一视图。
代码组织子项目还致力于确保 Kubernetes 保持在支持的 Go 版本上。链接的 KEP 提供了关于为什么需要这样做更多背景信息。我们与 SIG Release 合作，确保在 Go 发布版本上尽可能严格和尽早地测试 Kubernetes，并修复因此破坏 CI 的更改。这里可以找到我们如何跟踪此过程的示例。
发布周期和当前重点
FSM: 在发布周期中有没有什么变化？
MJ 在发布周期中，特别是在代码冻结之前，经常会有一些更改，包括添加/更新/删除依赖项，以及作为保持在受支持的 Go 版本的一部分而需要修复的代码。
此外，其中一些更改也是可以回移植到我们支持的发布分支的候选。
FSM: 子项目目前正在进行哪些你想重点介绍的重大项目或主题？
MJ: 我认为最近添加的一项非常有趣且极其有用的更改（借此机会特别强调Tim Hockin 在这方面的工作）是将 Go workspaces 引入 Kubernetes 仓库。这项更改可以显著改进我们目前用于依赖项管理和代码发布的许多工具，以及在 Kubernetes 仓库中编辑代码的体验。
总结
FSM: 对于对此主题感兴趣的人来说，如何开始帮助子项目？
MJ: 第一步，就像参与 Kubernetes 中任何项目的第一步一样，是加入我们的 Slack 群组：slack.k8s.io，然后加入 #k8s-code-organization 频道。我们还有代码组织 Office Hours，你可以选择参加。时区问题很复杂，所以你也可以查看录音或会议记录，并在 Slack 上跟进！
FSM: 太棒了，谢谢！你还有什么想分享的最后评论吗？
MJ: 代码组织子项目总是需要帮助！特别是在像 publishing bot 这样的领域，所以请不要犹豫，加入 #k8s-code-organization Slack 频道吧。