Gitは、 明示的な確約(commitment)なしに、 特殊なプラットフォームや古いプラットフォームに対して幅広い「サポート」を提供してきた歴史があります。 これらのプラットフォームの利害関係者は、 より予測可能なサポートの確約を望むかもしれません。 これは、 プラットフォームの利害関係者が Git 開発者に適切なツールを提供し、 互換性のテストやプラットフォーム固有の癖に対する回避策の開発を可能にする場合にのみ実現可能です。 プラットフォーム固有のツールのさまざまなレベルにより、 Git のそのプラットフォームとの互換性についてより確固たる確約を行うことができます。

注意: この文書は、 過去に一般的に機能していたプラットフォームに対する既存のサポートの維持に関するものです。 Git と一般的に互換性のないプラットフォームへのサポート追加については、 そのプラットフォームの利害関係者がその作業の大部分を自ら行うことが期待されます。 そのようなパッチは、 他のサポート対象プラットフォームや Git の貢献者にとって負担にならない場合に検討されます。 一部の貢献者が初期または継続的なサポートにボランティアとして協力する場合もありますが、 それは保証されるものではありません。 プロジェクトにとって過度にでしゃばり(intrusive)であったり、 維持が難しいサポート作業は、 依然として受け入れられない場合があります。

Minimum Requirements

この文書の残りの部分では、 プラットフォームがサポートしやすくするためのベストプラクティスについて説明します。 ただし、 サポートを検討する前に、 プラットフォームは以下の最低要件を満たす必要があります:

  • C言語の C99 または C11 をサポートしていること

  • 一般的に安定しており、 サポート可能な依存関係のバージョンを使用すること。 例えば、 他の長期サポート・ディストリビューションで使用されているバージョンに準拠すること

  • アクティブなセキュリティ・サポートを備えていること(依存関係のセキュリティ・リリースの適用など)

これらの要件は出発点であり、 Git コミュニティがあなたのプラットフォームを積極的にサポートするのにこれで十分という訳ではありません。 これらの要件を満たすプラットフォームのメンテナーは、 以下の手順に従うことで、 Git のアップデートがプラットフォームのニーズを尊重する可能性を高めることができます。

Compatible by next release

あるリリースで導入された互換性の問題がその後のリリースで修正される可能性を高めるためには:

  • あなたのプラットフォームで問題が発生したことに気づいたら、 すぐにバグ・レポートを送信する必要があります。 早く気づくほど良いです。 seen ブランチを監視することで、 レビュー終了(done with review)とみなされる前に問題に気づくことができます。 一方、 master ブランチを監視することは、 安定版のブランチがあなたのプラットフォームで壊れる可能性があることを意味しますが、 タグ付きリリースで問題が発生するのを避けられる可能性は十分にあります。 Git プロジェクトでどのブランチがどのように使用されているかの概要については、 "How to maintain Git" の「The Policy」を参照してください。

  • バグレポートには、 使用しているプラ​​ットフォームに関する情報が含まれている必要があります。

  • また、 git-bisect(1) を使用して、 どのコミットが破損を引き起こしたかを判断する必要があります。

  • 問題の性質に関するあらゆる情報を含めてください。 それはメモリのアライメント問題ですか？ それとも、 あなたのプラットフォームで基礎となるライブラリが欠けているか、 壊れていますか？ それとも、 あなたのプラットフォームに特有の癖があり、 通常の慣行(例えばmalloc)が異常な動作をする原因になっていますか？

  • 可能であれば、 あなたのプラットフォームと主流のプラットフォームの両方で、 まったく同じソースから Git をビルドして、 気づいた問題があなたのプラットフォームだけで発生するかどうかを確認してください。 両方のプラットフォームで問題が発生する場合、 それは互換性の問題ではありませんが、 すべてのプラットフォームのユーザーのために、 バグレポートでその情報を提供していただければもちろんありがたく思います。 問題があなたのプラットフォームだけで発生する場合は、 レポートでそれが互換性の問題であることを明確に記載してください。

  • 問題の修正を開始したら、 問題に取り組んでいる貢献者(contributor)と緊密に連携して、 提案された修正をプラットフォームに対してテストしてください。

例: NonStop に関して気づいた事のレポート reports problems

Compatible on master and releases

すべての安定版ビルドと定期リリースがあなたのプラットフォームで最初から動作するように、 master ブランチがあなたのプラットフォームで壊れないように支援してください:

  • あなたは next ブランチに対して定期的にテストを実行し、 破損レポートが発生したらすぐにメーリング・リストに公開する必要があります。

    • 理想的には、 これらのテストは毎日実行されるべきです。 少なくとも週に1回以上実行する必要があります。 なぜなら、 トピック達は通常 next で少なくとも7日間過ごしてから master に移行し、 パッチが next に取り込まれた後でその進行を止めるには時間がかかるからです。

    • あなたは、 そこでの提案された修正に対してテストを実行するために、 security mailing list への参加を希望するかもしれません。

  • これらを自動化することは理にかなっているかもしれません。 自動化する場合は、 ノイズが多くならないように注意してください(すべてが正常に動作しているときにレポートを送信する必要はありません。 問題が発生したときだけ送信してください。 同一問題について毎晩繰り返しレポートを送信する必要もありません)。

  • 問題レポートは実行可能であるべきです。 つまり、 あなたのプラットフォームで直接テストできない開発者に役立つような、 明確なエラーメッセージを含めてください。

  • あなたは git-bisect を使用して、 どのコミットが問題を引き起こしたかを特定する必要があります。 自動化でこれを行えない場合は、 問題レポートが送信されたことに気づいたらすぐに手動でこれを行うべきです。

  • あなたは以下のいずれかを行う必要があります:

    • 問題の修正に取り組んでいる信頼できる開発者にプラットフォームへのオンデマンド・アクセスを提供し、 修正をテストできるようにするか、

    • 問題を修正する開発者と密接に協力してください。 彼らが提案した修正があなたのプラットフォームで動作するかを確認する対応時間(turnaround)は、 修正作業を行う開発者を妨げないほど十分に速くなければなりません。 テストの対応時間が遅いと、 修正が次のリリースに間に合わなかったり、 開発者がその修正作業への興味を失ったりする可能性があります。

例: AIX はビルド・ファームを提供し、リリース候補に対してテストを実行します。

Compatible on next

変更がリリースまたは安定版ブランチに反映される際の脊髄反射的なデバッグや修正(reactive debugging and fixing)を避けるために、 next が常にあなたのプラットフォームで動作するようにすることを目指す事ができます。 そのためには… : (なお、 Git プロジェクトで next がどのように使用されているかの概要については、 "How to maintain Git" の 「The Policy」を参照してください。)

  • あなたのプラットフォームのためのランナー(runner)を GitHub Actions または GitLab CI スイートに追加する必要があります。 このスイートは、 Git 開発者が新しいパッチを提案したときに実行されます。 あなたの プラットフォーム/構成用 のランナーがあるということは、 誰かが問題を起こしたかどうかをすべての開発者がすぐに知ることができることを意味します。

    • (アーキテクチャ上の制約またはパフォーマンス上の理由により)既存の CI スイートに追加することが不可能な場合は、 できるだけ自動的かつ迅速に実行される他の方法で実行します。 たとえば、 メーリング・リストをチェックし、新しい パッチ・メール に対して自動的にテストを実行し、 結果を作成者に返信するサービスも、 この要件の精神に含まれます。

  • もし、 Git が特定のパターン(たとえば、 ある種の malloc パターン)の使用を避けていることが、 あなたのプラットフォームでうまく動作しない原因になっている場合は、 メーリングリストでそのことを提起してください。 他のプラットフォームとの互換性を保ちつつ、 不要な制約をかけないようにしながら、 ケース・バイ・ケースで解決策を検討していきます。

  • 一部の構成または振る舞いに依存している場合は、 そのためのテストを追加します。 テストされていない振る舞いは常に破損する可能性があります。

    • これらのテストがプラットフォーム互換性のために必要であることを明確にラベル付けしてください。 互換性に関連するテストだけをまとめた独立したテスト・スイート(新しい t* ファイルやユニット・テスト・スイートなど)に追加し、 互換性が不要になったときに簡単に削除できるようにしておきましょう。特定の互換性の必要性が他のプロジェクトの問題によって生じている場合は、 その問題のドキュメント(バグ報告やメール・スレッドなど)へのリンクを付けておくことで、 互換性の必要性がいつ解消されるかを判断しやすくなります。

    • これらのテストには、 1年以内の期限を記載したコメントを必ず含めてください。 もしその後もあなたのプラットフォームでその互換性が必要であれば、 期限を更新しても構いません。 ただし、 その互換性のケースに今も関心があり、 不要にするための取り組みを続けていることが分かるようにしておく必要があります。

例: 我々は CI suite を Windows や Ubuntu や Mac などで実行しています。

Getting help writing platform support patches

一般に、 プラットフォーム・サポートの問題を修正するパッチを送信する場合は、 以下のガイドラインに従って、 パッチが適切なレベルの緊急度でレビューされるようにしてください:

  • コミット・メッセージに、 プラットフォームの破損を修正していることと、 どのプラットフォームを対象としているかを明確に記載してください。

  • CI とテスト・スイートを使用して、 プラットフォームの修正が他のプラットフォームに影響を与えないことを確認します。

  • 可能であれば、 当該のデグレが再び起こらないことを確認するテストを追加してください。 テストを追加できない場合は、 コミット・メッセージでその理由を説明してください。

Platform Maintainers

あなたが、 プラットフォーム、 またはそのプラットフォーム用の Git を保守しており、 互換性を確保するために Git プロジェクトと連携する予定がある場合は、 パッチを送信して自分自身をこのリストに追加してください。

NonStop: Randall S. Becker <rsbecker@nexbridge.com>