Go Wiki: ポートポリシー

はじめに

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

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

新しいポートの要件

ポートに関連するコードを Go のメインリポジトリに追加する前に、以下のすべてが完了している必要があります。

  • Go チームが新しいポートをコア Go ツリーに含めることに対する全体的な責任を受け入れるプロポーザルが提出され、承認されていること。一般的に、新しいポートには、直接的なメンテナンスとは別に維持費用がかかります。その費用は、新しいポートが既存のポートとどれだけ似ているかによって異なります。この費用は、Go の潜在的な新規ユーザーやユースケースという形で、全体的な利益によって相殺される必要があります。

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

    • ポートメンテナーは、@golang/port-maintainers のサブチームに記載されています。既存のポートのメンテナーとして追加または削除されるには、課題を提出してください。
    • 特定のポートに固有の変更は、通常、まずポートメンテナーの一人（もちろん、変更を記述した人物ではない）によってレビューされるべきです。現在、各変更には2つのレビューが必要であるため、変更は引き続き通常、ポートメンテナーではない人物によってレビューされますが、理想的には、ポートの詳細にあまり詳しくない人物によるよりカジュアルなレビューで済みます。

  • 各 git リビジョンを試行し、https://build.golang.org のデータを提供するマシンであるビルダーを維持する開発者が指名されている（かつ同意している）こと。

  • ビルダーはすでに稼働していること（そして、コードがまだメインリポジトリにないため、失敗していること）。

  • 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 は通常 macOS の新しいバージョンを1つ発行し、古いバージョンを1つ非推奨にします。Go は通常、同じレートで古い macOS バージョンを非推奨にします。
  • 実際のまたは予想されるユーザーベース。ユーザーが比較的少ない場合、ポートを維持するためのかなりの努力は報われないかもしれません。
  • 継続的なコスト。継続的なデバッグや実装の努力を必要とするポートは、そうでないポートよりも厳しく精査されます。

考慮事項がポートの削除に有利に働き、プロポーザルが承認された場合、Go 1.N のリリースノートで、特定のオペレーティングシステムまたはアーキテクチャのサポートが Go 1.(N+1) で削除されることが発表されます。

入門

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

コメントと質問

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

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

go.dev は、サービスの品質を提供および向上させ、トラフィックを分析するために、Google の Cookie を使用しています。詳細はこちらをご覧ください。