Go Wiki：移植策略

简介

本文档介绍了将新端口添加到 Go 主存储库的策略。端口是指操作系统 + 架构组合，例如 linux/386。

此策略的目标是阐明 Go 项目试图为端口承诺的内容，并避免积累不完整或损坏的端口。

新端口的要求

在将与端口相关的任何代码添加到 Go 主存储库之前，必须完成以下所有操作

• 必须提交并接受一个提案，其中 Go 团队接受对核心 Go 代码树中包含新端口的总体责任。一般来说，每个新端口都会产生与直接维护分开的维护成本。此成本因端口而异，具体取决于新端口与现有端口的相似程度。必须通过潜在的新用户或 Go 的新用例形式的整体效益来平衡成本。

• 必须指定至少两名开发人员（并同意）维护端口，以便随着架构或操作系统要求的变化及时进行必要的更新。

  • 端口维护人员列在@golang/port-maintainers的子团队中。要添加或删除现有端口的维护人员，请提交问题。
  • 特定于某个端口的更改通常应首先由其中一位端口维护人员审查（当然，不是编写更改的人员）。我们目前要求对每个更改进行两次审查，因此更改通常仍将由非端口维护人员审查，但理想情况下，这可以由不太熟悉端口细节的人员进行更随意的审查。

• 必须指定一名开发人员（并同意）维护构建器，即尝试每个 Git 修订版并为https://build.golang.org提供数据的机器。

  • 构建器维护人员列在x/build/dashboard/builders.go中。要更新构建器的拥有者，请发送更改到该文件。

• 构建器必须已经在运行（并且失败，因为代码尚未在主存储库中）。

• 必须已发送所有必要的 CL 以成功运行 all.bash 进行审查。通常，这将是一小部分 CL，按它们更改的树的部分进行拆分。

一旦满足这些条件，Go 团队就可以接受端口并开始合并 CL。提交所有 CL 后，all.bash 必须通过，以便构建器在仪表板中报告“ok”。

其他存储库

尽管它不是核心存储库的一部分，但 x/sys 存储库应在发布之前添加对新端口的支持，因为它是在添加新系统调用的官方位置。在处理主存储库之前，在 x/sys 存储库中添加对新端口的支持是可以的。

一等端口

某些端口被认为是一等端口。区别主要在于版本发布。

一等端口具有以下属性

• 损坏的构建会阻止版本发布
  • 所有贡献者实际上都负责这些端口（您破坏了它，您修复它，或找到可以修复它的人。）
  • 要求 Google 的 Go 团队拥有构建器机器
• 安装文档位于https://golang.ac.cn/doc/install

将端口升级为“一等”由 Google 的 Go 团队自行决定，并且需要一个已接受的提案。

当前的一等端口为

• darwin/amd64
• darwin/arm64
• linux/386
• linux/amd64
• linux/arm
• linux/arm64
• windows/386
• windows/amd64

所有 Linux 一等端口仅适用于使用 glibc 的系统。使用其他 C 库的 Linux 系统不受完全支持，也不被视为一等端口。

维护端口

一般来说，更改 Go 工具和标准库的人员不得破坏上面列出的任何一等端口。破坏一等端口的更改必须修复或回滚。

破坏辅助端口的更改不一定需要回滚。如果存在破坏辅助端口的合理可能性，鼓励开发人员确保端口继续工作（例如，通过运行特定于端口的 trybots）。还鼓励开发人员通知辅助端口维护人员任何可能的特定于端口的问题，他们可以通过联系相应的GitHub 团队来做到这一点。也就是说，最终端口维护人员负责保持其端口的工作状态。

损坏的端口

• 如果端口停止工作，包括构建器停止工作的情况，我们可以决定将端口标记为损坏。
  • 或者在某些情况下，我们可以回滚导致其损坏的更改；这是一个判断问题。
• 一般来说，如果端口的构建器在一个开发周期中多次失败，并且失败模式在一等端口中没有发生，并且认为此失败模式尚未通过 Go 存储库或构建器配置中的更改得到修复或抑制，并且维护人员没有积极地寻求解决方案，则可以认为该端口已损坏。
• 任何批准者都可以声明符合这些条件的端口已损坏。
• 如果端口在 1.N 版本中损坏，则核心 Go 团队可以选择从 1.N+1 版本中删除该端口。
  • 这不是强制性的，将取决于是否有人愿意并且能够继续维护该端口。

这里的目标不是从代码树中删除端口；如果人们正在积极地处理该端口，则应尽可能地让他们有自由修复它。删除以前工作的端口应该是最后的选择。找到新的维护人员总是更好的。

删除旧的操作系统和架构版本

为了使开发工作能够专注于 Go 用户广泛使用的系统，随着时间的推移，我们可能会删除对旧的操作系统和架构的支持，尤其是旧的操作系统版本和架构修订版。

决定是否删除对旧操作系统或架构版本的支持时，需要考虑的重要事项是

• **可用性。**例如，如果操作系统不再分发或硬件不再制造，则没有明确的需要继续运行它。例如，Go 的 ppc64 端口不再支持 IBM POWER5 架构。
• **制造商支持。**如果操作系统或架构不再受其制造商支持，则强烈表明 Go 的未来版本也可以删除支持。例如，苹果公司每年通常会发布一个新版本的 macOS 并弃用一个旧版本。Go 通常会以相同的速率弃用旧的 macOS 版本。
• **实际或预期的用户群。**如果用户相对较少，则维护端口的重大工作可能不值得。
• **持续成本。**需要大量持续调试或实施工作的端口将比不需要的端口受到更严格的审查。

当这些考虑因素有利于删除端口并且提案被接受时，Go 1.N 的发行说明将宣布 Go 1.(N+1) 中将删除对给定操作系统或架构的支持。

入门

请参阅https://groups.google.com/forum/#!topic/golang-dev/SRUK7yJVA0c，了解有关如何编写新端口的一些讨论。

评论和问题

有关此策略的评论或问题应发送到 golang-dev。

此内容是Go Wiki的一部分。