Go Wiki: ポート移植ポリシー

はじめに

このドキュメントは、メインのGoリポジトリに新しいポートを追加するためのポリシーについて説明しています。ポートとは、linux/386など、オペレーティングシステムとアーキテクチャの組み合わせを意味します。

このポリシーの目標は、Goプロジェクトがポートに対して何を約束しようとしているかを明確にし、不完全または破損したポートの蓄積を防ぐことです。

新しいポートの要件

ポートに関連するコードをメインのGoリポジトリに追加する前に、次のすべてを実行する必要があります。

• GoチームがコアGoツリーに新しいポートを含めることに対する全責任を負うことを承認する提案を提出して承認する必要があります。一般的に、各新しいポートには、直接的なメンテナンスとは別に維持費用がかかります。その費用はポートによって異なり、新しいポートが既存のポートとどの程度似ているかによって異なります。その費用は、Goの潜在的な新規ユーザーまたはユースケースという形で得られる全体的なメリットによってバランスが取れている必要があります。

• 少なくとも2人の開発者を指名し（そして同意を得て）、アーキテクチャやオペレーティングシステムの要件が変更された場合にタイムリーに必要な更新を行うことで、ポートを維持する必要があります。

  • ポートメンテナーは、@golang/port-maintainersのサブチームにリストされています。既存のポートのメンテナーとして追加または削除するには、issueを提出してください。
  • 特定のポートに固有の変更は、通常、ポートメンテナーの1人によって最初にレビューされる必要があります（もちろん、変更を書いた人自身ではありません）。現在、変更ごとに2回のレビューが必要です。そのため、変更は通常、ポートメンテナーではない誰かによってレビューされますが、理想的には、ポートの詳細にあまり詳しくない人によるよりカジュアルなレビューにすることができます。

• 各gitリビジョンを試行し、https://build.golang.orgのデータを提供するマシンであるビルダーを維持する開発者を指名し（そして同意を得る）必要があります。

  • ビルダーメンテナーは、x/build/dashboard/builders.goにリストされています。ビルダーの所有者を更新するには、そのファイルに変更を送信してください。

• ビルダーは既に実行されている必要があります（そして、コードはまだメインリポジトリにないため、失敗しています）。

• all.bashを正常に実行するために必要なすべてのCLがレビューのために送信されている必要があります。通常、これは、変更するツリーの部分によって分割された少数のCLになります。

これらの条件が満たされると、Goチームはポートを受け入れ、CLのマージを開始できます。すべてのCLが提出されると、all.bashはパスする必要があり、ビルダーはダッシュボードに「ok」と報告します。

その他のリポジトリ

コアリポジトリの一部ではありませんが、x/sysリポジトリは、新しいシステムコールを追加する公式の場所であるため、リリースが行われる前に新しいポートのサポートを追加する必要があります。メインリポジトリで作業する前に、x/sysリポジトリに新しいポートのサポートを追加しても問題ありません。

ファーストクラスポート

一部のポートは「ファーストクラス」と見なされます。その違いは主にリリースに関するものです。

ファーストクラスポートには、次の特性があります。

• ビルドの失敗はリリースをブロックします
  • すべての貢献者は、これらのポートに対して効果的に責任を負います（壊したら、自分で修正するか、修正できる人を探してください）。
  • GoogleのGoチームがビルダーマシンを所有する必要があります
• インストール方法はhttps://go.dokyumento.jp/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ツールと標準ライブラリを変更する人は、上記のファーストクラスポートを壊してはなりません。ファーストクラスポートを壊す変更は、修正するかロールバックする必要があります。

セカンダリポートを壊す変更は、必ずしもロールバックされません。セカンダリポートを壊す可能性がある場合、開発者はポートが引き続き機能することを確認することをお勧めします（たとえば、ポート固有のトライボットを実行することにより）。開発者は、適切なGitHubチームに連絡することで、考えられるポート固有の問題についてセカンダリポートメンテナーに通知することもお勧めします。ただし、最終的には、ポートメンテナーが自分のポートの動作を維持する責任を負います。

破損したポート

• ビルダーが動作しなくなった場合を含め、ポートが動作しなくなった場合、ポートを破損したとマークすることを決定できます。
  • または、場合によっては、それを壊した変更をロールバックすることもできます。これは判断の問題です。
• 一般的に、ビルダーが開発サイクルで複数回失敗し、その失敗モードがファーストクラスポートでは発生せず、その失敗モードがGoリポジトリまたはビルダーの構成のいずれかの変更によって修正または抑制されたとは考えられず、メンテナーが積極的に解決策に取り組んでいない場合、ポートは破損していると見なすことができます。
• 承認者は誰でも、これらの基準を満たすポートが破損していると宣言できます。
• リリース1.Nでポートが破損している場合、コアGoチームは、リリース1.N+1からポートを削除することを選択できます。
  • これは義務ではなく、将来ポートを維持する意思と能力があるかどうかによって異なります。

ここでの目標は、ツリーからポートを取り除くことではありません。人々がポートで積極的に作業している場合は、それを修正するために可能な限り多くの自由度を与える必要があります。以前は機能していたポートを削除することは、最後の手段とする必要があります。新しいメンテナーを見つける方が常に優先されます。

古いオペレーティングシステムとアーキテクチャのバージョンの削除

Goユーザーが広く利用できるシステムに開発努力を集中できるようにするために、時間の経過とともに、特に古いオペレーティングシステムのバージョンとアーキテクチャのリビジョンについては、古いオペレーティングシステムとアーキテクチャのサポートを削除することがあります。

古いオペレーティングシステムまたはアーキテクチャのバージョンに対するサポートを削除するかどうかを決定する際の重要な考慮事項は次のとおりです。

• 可用性。たとえば、オペレーティングシステムがもはや配布されていないか、ハードウェアがもはや製造されていない場合、それを継続する明確な必要性はありません。たとえば、Goのppc64ポートは、もはやIBM POWER5アーキテクチャをサポートしていません。
• メーカーサポート。オペレーティングシステムまたはアーキテクチャがメーカーによってサポートされなくなっている場合、Goの将来のバージョンでもサポートを削除できるという強いシグナルになります。たとえば、Appleは通常、毎年1つの新しいバージョンのmacOSを発行し、1つの古いバージョンを非推奨にします。Goは通常、同じ速度で古いmacOSバージョンを非推奨にします。
• 実際のユーザーベースまたは予想されるユーザーベース。ユーザーが比較的少ない場合、ポートを維持するための大きな努力は無駄になる可能性があります。
• 継続的なコスト。継続的なデバッグまたは実装の努力を必要とするポートは、そうではないポートよりも厳しく精査されます。

考慮事項がポートの削除を支持し、提案が承認された場合、Go 1. *N*のリリースノートには、特定のオペレーティングシステムまたはアーキテクチャのサポートがGo 1.（*N* + 1）で削除されることが発表されます。

はじめに

新しいポートの作成方法に関する議論については、https://groups.google.com/forum/#!topic/golang-dev/SRUK7yJVA0cを参照してください。

コメントと質問

ポリシーに関するコメントや質問は、golang-devに送信してください。

このコンテンツはGo Wikiの一部です。