しばらく前、優れたメンテナリティ会議で、私はいくつかの仲間のメンテナと、本当に大きなオープンソースプロジェクトのスケールアップと、GitHubがどのようにプロジェクトをスケールアップするかについて話しました。 Linuxカーネルには、GitHubのメンテナーが理解していない完全に異なるモデルがあります。 なぜ、どのように機能し、どのように異なるのかを説明する価値があると思います。



このテキストを書いたもう1つの理由は、「 メンテナーはスケールしない 」という私の話についてのHNに関する議論でした。そこでは、最も人気のあるコメントが「なぜこれらの恐竜は最新の開発ツールを使用しないのか？」 いくつかの有名なカーネル開発者は、GitHubプルリクエストに類似したメカニズムを通じてメーリングリストを積極的に防御し、パッチを提供しましたが、グラフィックスサブシステムの少なくとも数人の開発者は、スクリプトで自動化するのがはるかに簡単な最新のツールを使用したいと考えています。 問題は、GitHubがLinuxカーネルが膨大な数の貢献者に対応する方法をサポートしていないため、複数のサブシステムであっても単純に切り替えることができないことです。 そして、Gitでデータをホストすることではなく、この部分は明らかに順序が正しいのですが、問題はプルリクエスト、バグとフォークの議論がGitHubでどのように機能するかです。

GitHubスタイルのスケーリング

誰もが非常に簡単に分岐し、独自のブランチを作成し、コードを変更できるため、Gitはクールです。 最終的に価値のあるものが得られた場合は、メインリポジトリのプルリクエストを作成し、それをレビュー、テスト、およびマージします。 GitHubは、これらの複雑なものを楽しく、見つけやすく、簡単に習得するための適切なUIを導入したので素晴らしいです。そのため、初心者でも簡単にコースに参加できます。



しかし、結果としてプロジェクトが非常に成功し、タグ、タグ、並べ替え、ボット、および自動化の数がリポジトリ内のすべてのプル要求と問題にすでに対処できない場合、プロジェクトをより管理しやすい部分に再び分割するときが来ます。 さらに重要なことに、プロジェクトの特定のサイズと年齢では、異なる部分に異なるルールとプロセスが必要になります：輝く新しい実験ライブラリは、メインコードとは異なる安定性とCI基準を持っているか、既に除外されたプラグインの束を持つレガシーゴミ箱があるかもしれませんサポートされていませんが、削除することはできません。 何らかの方法で、巨大なプロジェクトをサブプロジェクトに分割する必要があります。各サブプロジェクトには、パッチをマージするための独自のプロセスと基準、およびプルリクエストと問題追跡が機能する独自のリポジトリがあります。 通常、フルタイムで作業する数十から数百人の貢献者が必要です。そのため、プロジェクトの頭痛の種は、プロジェクトを部分に分割する必要が生じるほど大きくなります。



GitHubのほとんどすべてのプロジェクトは、単一のソースツリーを多くの異なるプロジェクトに分割することで問題を解決します。それぞれのプロジェクトには独自の機能があります。 通常、これにより、コアと見なされる多数のプロジェクトに加えて、多数のプラグイン、ライブラリ、および拡張機能が表示されます。 すべては何らかのプラグインまたはパッケージマネージャーによって接続されており、場合によってはGitHubリポジトリからコードを直接受け取ります。



ほとんどすべての大規模プロジェクトはこのように構成されているため、このアプローチの利点を掘り下げる必要はないと思います。 しかし、この状況で発生する問題のいくつかを強調したいと思います。

• コミュニティが細分化されすぎています。 ほとんどの貢献者は、コードと対応するリポジトリを単純に処理しますが、他のすべてを無視します。 彼らにとっては本当にクールですが、異なるプラグインとライブラリ間の重複した努力と並列ソリューションに気付く確率は、時間内に大幅に減少します。 そして、コミュニティ全体を全体として管理したい人は、スクリプト、Gitサブモジュール、またはもっと悪いことによって管理されているたくさんのリポジトリに対処する必要があります。 さらに、何かをサブスクライブすると、プルリクエストと問題にdrれます。 個別のリポジトリに完全に収まらないトピック（ビルドやドキュメントなどを作成するための共通のツールキットがある場合）は、メンテナーにとって頭痛の種になります。
• リファクタリングとコード共有の必要性に気付いたとしても、より多くの官僚的な障害があります。まず、新しいバージョンのキーライブラリをリリースし、すべてのプラグインを調べて更新する必要があります。その後、共有ライブラリの古いコードを削除できます。 しかし、すべてが非常に散らばっているため、最後のステップを忘れることができます。
  
  
  
  もちろん、これはすべてそれほど多くの作業を必要とせず、多くのプロジェクトは経営陣と素晴らしい仕事をします。 ただし、単一のリポジトリへの単純なプルリクエストよりも多くの労力が必要です。 非常に単純なリファクタリング操作（単一の新しい関数の単純な共有など）の発生頻度は低く、時間の経過とともにこれらのコストは累積します。 node.jsの例に従って、各機能のリポジトリを作成し、Gitをソース管理システムとしてnpmに本質的に変更する場合を除き、これも奇妙に思えます。
• 理論的にサポートされているさまざまなバージョンの組み合わせの爆発により、事実上サポートされなくなりました。 ユーザーは統合テストを実行する必要があります。 そして、プロジェクトでは、承認された（「祝福された」）バージョンの組み合わせになります。または、少なくともこれは事実上宣言されています。開発者は単に「すべてのモジュールを最初に更新してください」という言葉でバグレポートを閉じるからです 繰り返しますが、これは、Gitではなく、実際に単一のリポジトリを持っていることを意味します。 さて、サブモジュールを使用する場合にのみ、これがGitと見なされるかどうかはわかりません...
• 共有プロジェクトをサブプロジェクトに分割するときは、Gitリポジトリとそれらの分割方法を再編成する必要があるため、苦痛を伴う再編成です。 単一のリポジトリで、メンテナーを変更すると、OWNERまたはMAINTAINERSファイルが更新されるだけで、ボットが正常であれば、新しいメンテナーはタグを自動的に受け取ります。 ただし、スケーリングがリポジトリを異なるセットに分割することを意味する場合、再編成は、単一のリポジトリから分割されたリポジトリのグループへの最初のステップと同じくらい苦痛になります。 これは、プロジェクトが長期にわたって不適切な組織構造にとどまることを意味します。

間奏：プルリクエストがある理由

Linuxカーネルは、私が知っているいくつかのプロジェクトの1つであり、この方法では分割されていません。 それがどのように機能するかを見る前に（カーネルは巨大なプロジェクトであり、サブプロジェクトの構造がなければ機能しません）、Gitでプルリクエストが必要な理由を見るのは興味深いようです。 GitHubでは、これが開発者が提案されたパッチを共通コードに組み込むことができる唯一の方法です。 しかし、カーネルの変更は、Gitの導入と広範囲な使用のずっと後でさえ、メーリングリストのパッチとして提供されます。



しかし、すでにGitの最初のバージョンはプルリクエストをサポートしていました。 これらの最初のかなり生のリリースの対象はカーネルメンテナーでした。GitはLinusのメンテナーの問題を解決するために書かれました。 明らかに、Gitは必要で便利でしたが、個々の開発者からの変更を処理するためではありませんでした：今日でさえ、プルリクエストはサブシステム全体への変更の処理、リファクタリングされたコードの同期、または異なるサブプロジェクト間の同様のクロスカット変更に使用されました。 一例として、 Linusが提供する Dave Millerからの4.12ネットワークプルリクエストには、600人の開発者からの2,000を超えるコミットと、下位のメンテナーからのプルリクエストに対する多くのマージが含まれています。 しかし、ほとんどすべてのパッチ自体は、作成者自身ではなく、メンテナーによって提示され、メーリングリストから選択されます。 これはカーネル開発の機能であり、通常、作成者は共有リポジトリにパッチをコミットしません。そのため、Gitはパッチの作成者とコミットの作成者を別々に考慮します。



GitHubの技術革新と改善は、個々のパッチに至るまで、すべての行に対してプルリクエストを使用することでした。 ただし、これのためではなく、プルリクエストは最初に作成されました。

Linuxカーネルのスケーリング

一見すると、カーネルは単一のリポジトリのように見え、Linusのリポジトリのすべてが1か所にあります。 しかし、これはそうではありません。

• Linus Torvaldsのメインリポジトリを使用する人はほとんどいません。 アップストリームからの何かが彼らのために働くなら、通常それは安定したカーネルの 1つです。 しかし、ディストリビューションのカーネルを持っている可能性が非常に高く、通常は追加のパッチとバックポートがあり、 カーネルカーネルもホストしていません。これはまったく別の組織です。 または、ハードウェアベンダー（SoCおよびAndroidに関連するほとんどすべて）のカーネルを持っています。これは、「メイン」リポジトリのいずれかでホストされているすべてのものとは大幅に異なります。
• 誰も（Linus自身を除いて）Linusリポジトリ用の何かを開発しません。 各サブシステム、および大規模なドライバーでさえ、多くの場合、独自のGitリポジトリがあり、パッチを追跡し、他の人から完全に隔離された問題を議論するための独自のメーリングリストがあります。
• サブシステム間の作業は、ほぼ同じ数のGitリポジトリーからの数百のGitブランチを含むlinux-next統合ツリーの上部で実行されます。
• このすべての狂気は、 MAINTAINERSファイルとget_maintainers.plスクリプトによって制御されます。このスクリプトは、特定のコードスニペットごとに、メンテナー、コードをチェックする人、正しいGitリポジトリの場所、使用するメーリングリスト、バグを報告する方法および場所を伝えることができます。 情報は、ファイルの場所に基づいているだけではありません。 また、コードテンプレートを分析して、デバイスツリーのメンテナンスやkobject階層などのサブシステム間トピックが適切な専門家によって処理されていることを確認します。

一見すると、各ディスクスペースを彼にとって面白くない一連のナンセンスで埋める洗練された方法のように見えますが、相互に重複する多くの関連する小さな利点があります。

• サブプロジェクト内のものを強調表示して再編成するのは完全に簡単です-MAINTAINERSファイルを更新するだけで完了です。 新しいリポジトリ、新しいメーリングリスト、および新しいbugzillaを作成する必要がある場合があるため、残りは必要以上に複雑です。 これは、GitHubがクールな小さなフォークボタンでエレガントに解決したUIの問題です。
• サブプロジェクト間でプルリクエストや問題の議論を翻訳するのは非常に簡単です。答えのCc：フィールドを変更するだけです。 また、1つのプルリクエストを複数のサブプロジェクトに送信でき、（Msg-Idsタグ：メーリングリストのスレッドはすべてのユーザーで同じであるため）1つのプルリクエストを送信できるため、サブシステム間の作業を調整するのもはるかに簡単です。メーリングリストはさまざまなメーリングリストを通過し、数千の異なるメールボックスにあります。 サブプロジェクト間のトピックとコードの簡単な説明は、断片化を回避するのに役立ち、一般的なコードとリファクタリングの使用が役立つ場所に気付くのは簡単です。
• サブシステム間の作業には、リリースを伴うダンスは一切必要ありません。 コードを変更するだけです。コードはすべて単一のリポジトリにあります。 これは、個別のリポジトリで可能なよりもはるかに効率的であることに注意してください。 本当にアグレッシブなリファクタリングの場合、たとえば、あまりにも多くのユーザーがいて、調整の問題をあまり引き起こさずに一度にすべてを変更できる場合など、複数のリリース間で作業を単純に分割できます。
  
  
  
  大きな利点は、リファクタリングとコード交換が簡単になったことです。たくさんのレガシーガベージを持ち歩く必要はありません。 これは、安定したAPIを使用したせん妄の不在に関するドキュメントで詳細に説明されています 。
• 独自の実験的なアドオンの作成を妨げるものは何もありません。これは、多くのリポジトリを備えたシステムの重要な利点の1つです。 彼らは彼らのコードをフォークに追加してそこに残しました-誰もあなたがコードを押し戻したり、1つの共通リポジトリにプッシュしたり、メイン組織に転送したりすることを強制することはありません。 さまざまなAndroidハードウェアベンダーリポジトリのブランチの外にある数百万行のコードが示すように、これは本当にうまく機能しています。

一般的に、これははるかに強力なモデルだと思います。なぜなら、多くの切断されたリポジトリと同じようにいつでもロールバックしてすべてを実行できるからです。 地獄、Nvidia独自のドライバーのように、メインカーネルとは別の独自のリポジトリに常駐するカーネルドライバーもあります。 まあ、それはブロブの周りにソースコードを接着するようなものですが、法的な理由でカーネル部分が含まれていない可能性があるため、これは素晴らしい例です。

モノリポジトリについてのホラー映画のように見えます！

はい、いいえ。



一見すると、Linuxカーネルはすべてを備えているため、モノリポジトリのように見えます。 また、多くの人は、特定のサイズからは単純にスケーリングできないため、モノリポジトリが多くの問題を引き起こすことを自分の経験から知っています。



しかし、よく見ると、そのようなモデルは、単一のGitリポジトリから非常に遠く離れています。 すでに数百を提供しているのは、アップストリームサブシステムとドライバーリポジトリのみです。 ハードウェアベンダー、ディストリビューション、その他のLinuxベースのオペレーティングシステム、個々の製品を含むエコシステム全体を見ると、数千のメインリポジトリやその他の多くのリポジトリを簡単に数えることができます。 そして、これは、Gitリポジトリを除き、純粋に個々の開発者が個人的に使用するためのものです。



主な違いは、Linuxでは、すべての共通のネームスペースとして単一のファイル階層がありますが、あらゆる種類のニーズやプロジェクトには多くの異なるリポジトリがあることです。 それは多くのリポジトリを持つモノツリーであり、モノリポジトリではありません。

例を挙げてください！

GitHubが現在このようなワークフローを提供できない理由を説明する前に、少なくともGitHub UIと統合の利点を維持したい場合は、実際にどのように機能するかの例を見る必要があります。 要するに、すべてはメンテナー間のGitプルリクエストを通じて行われます。



単純なケースは、メンテナーの階層を介した変更の通過であり、必要に応じて最終的にツリーに落ち着きます。 これは簡単です。プルリクエストは常にあるリポジトリから別のリポジトリに送られるため、現在のGitHub UIを使用して行うことができます。



非循環グラフからのプルリクエストがグリッドに変わるため、サブシステム間の変更がさらに楽しくなります。 最初の段階では、変更を検討し、関係するすべてのサブシステムとメンテナーで変更をテストする必要があります。 GitHubワークフローでは、これは複数のリポジトリへのリクエストを同時にプルし、それらのリポジトリ間で単一のディスカッションストリームを作成することを意味します。 カーネル開発では、このステップはパッチをさまざまなメーリングリストに送信し、メンテナーを受信者として指定することで実現されます。



マージは、パッチの検討とは異なります。 ここでは、サブシステムの1つがすでにメインサブシステムとして選択されており、すべてのプル要求を受け取り、他のすべてのメンテナーがこのマージオプションに同意しています。 通常、変更の影響を最も受けやすいサブシステムを選択しますが、プル要求と競合する作業がすでに進行中のサブシステムを選択することもあります。 時には、まったく新しいリポジトリとメンテナーのチームを作成します。 これは多くの場合、ツリー全体に及ぶ機能で発生し、1つの場所にある複数のファイルやディレクトリにきちんと含まれていません。 最近の例としては、 DMAマッピングツリーがあります 。これは、ドライバー、プラットフォームメンテナー、およびアーキテクチャサポートグループに分散された作業をまとめることを試みます。



しかし、一連の変更と競合するサブシステムが多数あり、誰もが何らかの形で非自明なマージ競合を解決する必要がある場合があります。 この場合、パッチは直接適用されません（GitHubのRebaseプルリクエスト）が、代わりにプルリクエストはすべてのサブシステムに共通のコミットに基づいて必要なパッチでのみ使用されます-すべてのサブシステムツリーに適用されます。 このような共通基盤は、不必要な変更によるツリーサブシステムの汚染を回避するために重要です。 さらにプルするのは特定のトピックのみであるため、これらのブランチは通常テーマ別ブランチと呼ばれます 。



例として、HDMI経由のオーディオのサポートを提供できます。このプロセスに直接関与していました。 グラフィックスサブシステムとサウンドドライバーのサブシステムの両方に適用されます。 同じプル要求からの同じコミットが、Intelグラフィックドライバーとオーディオサブシステムに含まれています 。



完全に異なる例は、これが狂気ではないということです-世界で唯一の同等のOSプロジェクトは、Linuxと同様のコミットストリームを持つモノツリーも選択しました。 私はそれをサポートするために完全に新しいGVFS仮想ファイルシステムを作成しなければならないほど巨大なツリーを持つ人について話している...

親愛なるGitHub

残念ながら、GitHubはこのようなワークフローのサポートを提供していません。少なくともネイティブではGitHub UIはサポートしていません。 もちろん、これは単純なGitツールを使用して簡単に実行できますが、手動で実行されるメーリングリストパッチと電子メールプルリクエストに戻ります。 これが、カーネル開発者コミュニティがGitHubに切り替えてもメリットを享受できない唯一の理由だと思います。 また、いくつかの主要なメンテナーがGitHub全体に対して明確に反対しているという小さな問題もありますが、これはもはや技術的な問題ではありません。 そして、それは単なるLinuxカーネルではありません。 実際、GitHubのすべての巨大プロジェクトにはスケーリングに関する問題があります。これは、GitHubがモノツリーに関連付けられている多数のリポジトリにスケーリングする能力を実際に与えていないためです。



そのため、GitHubには1つの機能のみをリクエストしています。

1つのモノツリーのさまざまなリポジトリを対象に、プルリクエストとバグトラッキングを実装してください。

シンプルなアイデア、大きな結果。

リポジトリと組織

まず、同じ組織内で同じリポジトリの複数のフォークを可能にする必要があります。 git.kernel.orgをご覧ください 。ほとんどのリポジトリは非公開ではありません。 また、異なるサブシステムなど、異なる組織をサポートしている場合でも、各リポジトリに組織を置くという要件は愚かで冗長であり、アクセスとユーザー管理を制限する必要はありません。 たとえば、グラフィックスサブシステムでは、ユーザースペーステストスイートごとに1つのリポジトリ、共通のユーザースペースライブラリ、およびメンテナーと開発者が使用するツールとスクリプトの共通セットがあり、このGitHubはサポートされています。 ただし、その後、共通のサブシステムリポジトリに加えて、サブシステムの主要機能のリポジトリと、主要なドライバーごとに追加のリポジトリを追加します。 これらはすべてGitHubにはないフォークです。 そして、これらの各リポジトリには多数のブランチがあります。少なくとも1つは機能の作業用で、もう1つは現在のリリースのバグ修正用です。



リポジトリのセクションの意味はプルリクエストとバグを分離することでもあるため、リポジトリ内のすべてのブランチの組み合わせを提供しないでください。



関連する質問：事後、フォーク間の接続を確立できる必要があります。 常にGitHubにある新しいプロジェクトの場合、これは問題ではありません。 しかし、Linuxは一度に最大1つのサブシステムを移動できます。また、GitHubには、互いに正しく分岐していないLinuxリポジトリが既にたくさんあります。

プルリクエスト

プルリクエストは、単一の共通ディスカッションスレッドを維持しながら、同時に複数のリポジトリに関連付ける必要があります。 プル要求をリポジトリの別のブランチに既に再割り当てできますが、同時に複数のリポジトリに再割り当てすることはできません。 プルリクエストの再割り当ては非常に重要です。新しいプロジェクトの参加者は、メインリポジトリと見なすものに対してプルリクエストを作成するだけだからです。 ボットは、リポジトリに含まれる一連のファイルと変更のMAINTAINERSファイルにリストされているすべてのリポジトリを考慮してシャッフルできます。 GitHubのスタッフと話をしたとき、私は最初に彼らがこれを直接実装することを提案しました。 しかし、ここではスクリプトを使用してすべてを自動化できると思うので、単一の標準がないため、これを個々のプロジェクトにのみ残す方が良いと思います。



パッチのリストは、プルリクエストの送信先のブランチによって異なる可能性があるため、依然としてかなり厄介なUIの問題があります。 ただし、一部のリポジトリでは既にいくつかのパッチを適用できるため、これは常にユーザーエラーではありません。



さらに、プルリクエストのステータスはリポジトリごとに異なる必要があります。 あるメンテナーは、別のサブシステムが受け入れることを決定したので、別のメンテナーが質問をマージして閉じることがあるため、受け入れずに閉じることができます。 別のツリーでは、ベンダーからの古いバージョンまたはフォークには適用できないため、プルリクエストを無効として閉じることもできます。 さらに興味深いことに、プル要求は、各サブシステムで異なるコミットを使用して、マージを数回実行できます。

虫

プルリクエストと同様に、バグは多くのリポジトリに関連している可能性があるため、それらを移動できる必要があります。 例として、最初にカーネルリポジトリに報告されたバグを取り上げてみましょう。 ソート後、これは最後の開発ブランチに存在するドライバーのバグであることが明らかになりました。したがって、このリポジトリに加えて、メインのアップストリームブランチと、いくつかのその他のブランチを参照します。



1つのリポジトリにバグ修正が表示された後、すぐに他のすべての人が利用できるようになるわけではないため、ステータスは再び分離される必要があります。 カーネルやディストリビューションの以前のバージョンに移植する必要さえあるかもしれませんが、サブシステムの対応するリポジトリで問題なく解決されたとマークされている場合でも、誰かがバグに価値がないと判断してWONTFIXとして閉じるかもしれません。

結論：単一リポジトリではなく、単一ツリー

LinuxカーネルはGitHubに切り替わりません。 しかし、多数のリポジトリを持つモノツリーとしてLinuxスケーリングモデルに切り替えることは、GitHubにとって良いコンセプトであり、すでにそこでホストされているすべての非常に大規模なプロジェクトに役立ちます。 これは彼らに彼らのユニークな問題を解決するための新しいより効果的な方法を与えると思われます。