LinusはParagonに挑戦し、GitHubの合併を批判します

リーナス・トーバルズは 彼は、Linuxカーネルの開発を支援する人々が従わなければならない手順と標準について非常にうるさいです。 そして、彼は通常、その任務を果たせない人々にはあまり親切ではありません。 過去に彼が他の人々との関係を再考するためにしばらくの間彼の役割から撤退したことを思い出してください。

今回、彼の嫌悪感を被ったのは、NTFS3ドライバーの背後にある会社であるParagonSoftwareでした。  Linuxカーネルバージョン5.15で発表され、ネイティブWindowsファイルシステムのサポートが改善されます。

バージョン管理システム（MCS）

この話を理解するために、誰もが知っている必要のないいくつかの詳細を説明します。

非常に複雑なソフトウェアプロジェクトの開発者は、バージョン管理ソフトウェアを使用します（通常はクラウド内の外部プロバイダーによって運用されます） このソフトウェアを使用すると、誰が、いつ、何が変更を加えたかを追跡できます。

プロジェクトメンバーに属していない場合は、フォークを作成できます。つまり、プロジェクトファイルを独自のリポジトリにコピーし、その中で独自の変更を加えることができます。 結果が気に入った場合は、元のプロジェクトの管理者に、電話でそれらを組み込むように提案できます。 プルリクエスト。

コントローラのリリース

昨年、パラゴンソフトウェア彼は以前に販売したコントローラーコードのリリースを発表し、メンテナンスと更新の面倒を見ることにしました。NS。 これは、現在使用しているものよりもはるかに優れているため、朗報です。

会社自体によると

現在のバージョンは、通常の/圧縮された/広々としたファイルで動作し、acl、NTFSジャーナルの再生をサポートします。 ほとんどのコードは13月XNUMX日からlinux-nextブランチにありましたが、いくつかのパッチがあり、それらはlinux-nextブランチに数日間しかありませんでした。 うまくいけば、それは大丈夫です-テストで回帰は検出されませんでした。

パラゴンの発表後、 NTFS3ドライバーは、コードの品質を改善し、カーネルの他の部分のコーディング標準に準拠させるために、何度も改訂を行う必要がありました。

彼はついにそれを成し遂げたようです。

そして、私たちは羊の母のところに行きます。

ライナスはパラゴンを差し引く

カーネルバージョン5.15にドライバーを含めるために、 Linus Torvaldsは、ParagonSoftwareに プル要求 そのうち上で話しました。 同社はそれを行ったが、トーバルズが好む方法ではなかった。

フィンランド人の最初の観察はそれでした プルリクエストは署名されている必要があります。

完璧な世界では、これは信頼の鎖を介して直接あなたにたどることができるPGP署名ですが、私はそれを要求したことはありません。

第二に、彼はプルリクエストが これは、多くのジャンクコードを生成するサービスのWebインターフェイスから実行されていました。

Githubは完全に優れたホスティングサイトであり、他にも多くのことをうまく行っていますが、合併はそれらのXNUMXつではありません。

彼はまた抗議した 十分な情報の欠如。

Linuxの作成者にとって、「Linuxカーネルのマージは適切に行われる必要があります」。 そして追加：«これは、何がマージされているのか、*なぜ*何かがマージされているのかに関する情報を含む適切なコミットメッセージを意味します。 しかし、それはまた、著者やコミッターなどに関する適切な情報を意味します。 そのすべてがGitHubを完全に台無しにします。

Linus Torvaldsは、彼が何について話しているかを知っています。彼は、GitHubなどのサービスのベースとなるソフトウェアであるGitの作成者であり、現在はMicrosoftが所有しています。 そして、不思議なことに、それは別のサービスとの不一致によるものでした

私はそれらすべてを嫌っていたので、バージョン管理プログラムを作りたくありませんでした…その後、BitKeeperが登場し、私がそれらを見る方法が大きく変わりました。 BKはほとんどのことを正しく行い、リポジトリのローカルコピーと分散マージを行うことが非常に重要でした。 分散オリジンコントロールの優れている点は、MCSの主な問題のXNUMXつである「誰が変更を加えることができるか」をめぐる政治がなくなることです。

BKは、全員に独自のリポジトリを提供することで、これを回避できることを示しました。 しかし、BKにも独自の問題がありました。 問題を引き起こす技術的な決定がいくつかありましたが（名前の変更は苦痛でした）、最大の欠点は、オープンソースではないため、使用したくない人が多かったことです。 そのため、BKを使用するカーネルメンテナが何人かいたとしても（オープンソースプロジェクトには無料で使用できます）、大規模になることはありませんでした。したがって、カーネル開発には役立ちましたが、完璧ではありませんでした。

そのため、ある時点でBKを使い続けることはできないと判断しましたが、BK以前の古き良き時代に戻りたくありませんでした。 悲しいことに、当時、物事を配布しようとした他のSCVがいくつかありましたが、それらのどれもリモートでうまくいきませんでした。 利用可能なものではリモートでも満たされないパフォーマンス要件があり、コードとワークフロー全体の整合性にも関心があったため、自分で作成することにしました。