Go Wiki：PortingPolicy

引言

本文檔說明新增 port 到 Go 主要存放庫的政策。port 指的是一個作業系統 + 架構組合，例如 linux/386。

本政策的目標是釐清 Go 計畫對於 port 保證的範圍，並避免累積不完整或損毀的 port。

新增 port 的要求

在將與 port 相關的程式碼新增到 Go 主要存放庫之前，必須先完成以下所有事項：

• 必須提交 建議案 並獲得接受，而 Go 團隊需同意全面負責在 Go 核心樹中納入新的 Port。一般而言，每個新 port 都會承擔額外維護成本，這部分成本與直接維護無關。此成本會因 port 與現有 port 的相似性而異。必須以新使用者或 Go 的使用案例等形式，為此成本取得適當的平衡。

• 至少兩位開發人員必須被指名（並同意）維護該移植，即根據建構或作業系統需求的改變，即時提供必要的更新。

  • 移植維護者會出現在 @golang/port-maintainers 的子團隊清單中。若要新增或移除某現有移植的維護者，請 提出問題。
  • 一般來說，特定於某個移植的修改應首先由其中一位移植維護者審閱（但當然不能是由提出修改的人審閱）。我們目前要求每項修改都要經過兩次審閱，因此修改仍會由一位非移植維護者審閱，但理想來說可以由一位不太熟悉移植詳細資料的人進行較非正式的審閱。

• 必須指派一位開發人員（並同意）維護建構器，這部機器會針對每個 git 修訂進行嘗試，並提供資料給 https://build.golang.org。

  • 建構器維護者會出現在 x/build/dashboard/builders.go 中。若要更新某建構器的擁有者，請 將修改提交至該檔案。

• 建構器必須已經在執行（並且會失敗，因為程式碼尚未在 main 儲存庫中）。

• 所有讓 all.bash 成功執行的 CL 都必須已送出審查。這通常會是一些依據它們所修改的樹狀結構的部分拆分的 CL。

只要符合這些條件，Go 團隊便可以接受該移植並開始合併這些 CL。一旦所有 CL 都已提交，all.bash 就必須通過，讓建構器在面板中回報「正常」。

其他儲存庫

雖然 x/sys 儲存庫並非核心儲存庫的一部分，它應在發佈前新增對新移植的支援，因為它是新增系統呼叫的官方地方。在處理主儲存庫之前，先在 x/sys 儲存庫中新增對新移植的支援是可以接受的。

一流移植

某些移植被視為「一流」。此區別主要在於版本。

一流移植具有下列屬性

• 中斷的建構會阻擋版本發佈
  • 所有貢獻者都對這些移植負有實際責任（如果你中斷了它，你就要修復它，或找一位可以修復它的人。）
  • 要求 Google 的 Go 團隊擁有建構器機器
• 安裝文件已記載於 https://go.dev.org.tw/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 tool 和標準函式庫的人員不得中斷上述所列的任一流埠。中斷一流埠的變更必須修正或回滾。

中斷次要埠的變更並不一定會回滾。如果存在中斷次要埠的某種合理可能性，建議開發人員確保埠持續運作（例如，透過執行特定於埠的嘗試機器人）。也建議開發人員將任何可能的特定於埠的問題通知次要埠維護人員，他們可以透過與適當GitHub 團隊聯繫來這麼做。儘管如此，最終而言，埠維護人員有責任使他們的埠持續運作。

損壞的埠

• 如果埠停止運作（包括產生器停止運作的情況），我們可以決定將該埠標示為損壞。
  • 或者，在某些情況下，我們可以回滾損壞它的變更；這是項判斷依據。
• 一般來說，如果埠的產生器在開發週期中因不會發生在一流埠的失敗模式而多次失敗，且該失敗模式不被認為是由 Go 存放庫或產生器的配置變更修正或抑制，而維護人員也沒有積極處理解決方案，則可以認為該埠已損壞。
• 任何核准者都可以宣告符合這些條件的埠已損壞。
• 如果埠在 1.N 版中損壞，則 Go 核心團隊可以選擇從 1.N+1 版中移除該埠。
  • 這不是義務的，這取決於是否有人願意且有能力繼續維護該埠。

此處的目的不是從樹中移除埠；如果有人積極處理該埠，他們應該有儘可能多的修正緯度。移除先前運作的埠應該是最後手段。尋找新的維護人員總是很理想的。

移除舊作業系統和架構版本

隨著時間推移，為讓開發工作重點放在廣泛提供給 Go 使用者的系統上，我們可能會移除對舊作業系統和架構的支持，特別是舊作業系統版本和架構修訂。

決定是否移除對舊作業系統或架構版本的支援時，重要的考量因素包括

• 可用性。如果該作業系統已不再分發或硬體已不再製造，例如，沒有明確的需要再繼續使用它。舉例來說，Go 的 ppc64 埠已不再支援 IBM POWER5 架構。
• 製造商支援。如果製造商已不再支援作業系統或架構，那這代表 Go 的未來版本也很可能移除支援。例如，Apple 每年通常會發布一個新的 macOS 版本，並停用一個舊版本。Go 通常會以相同的速度停用舊的 macOS 版本。
• 目前的或預期的使用者基礎。如果使用者相對較少，維護埠的大量工作可能不值得。
• 持續成本。需要大量持續除錯或實作工作量的埠，會比不需要這些工作的埠受到更多檢視。

在考慮移除埠之後，若提案通過，Go 1.N 的版本說明會公告，在 Go 1.(N+1) 中移除對特定作業系統或架構的支援。

開始

有關如何撰寫新埠的一些說明，請參閱https://groups.google.com/forum/#!topic/golang-dev/SRUK7yJVA0c。

評論和問題

關於政策的評論或問題應傳送至 golang-dev。

此內容是Go Wiki的一部分。