電子メールで開催されるLinuxカーネル開発

約1万5千人の開発者と222社がリリース間で1万2千以上の変更または1時間ごとに7/8の編集を行う最大のオープンソースプロジェクトの開発をどのように管理しますか？ カーネルクリエーターのLinus Torvalds、 安定したブランチメンテナーの Greg Croah-Hartman（GKH）、および他の仲間は、プロジェクトの作業を正常に調整し、各新しいバージョンのタイムリーなリリースを保証するために何を使用しますか？

このすばらしいツールは、テキストベースのメールクライアントですMutt 、Linus TorvaldsはAlpineです。 3位のコア開発者であるAndrew Mortonも、電子機器を使用してmmブランチを制御しています。

GitHub、Gerrit、その他のソフトウェア開発方法など、より多様な「最新」の開発ツールを使用しているのに、なぜLinuxカーネルチームは、パッチを受け入れるためにプレーンテキストメールの古代の要件に1990年代に留まっているのですか？ この講演では、カーネル開発プロセスがどのように機能するのか、これらの「古代の」ツールに依存する理由、そして他のどのツールよりも優れた機能を発揮するのかについて説明します。 ^[1]

これがどのように発生するかを理解してみましょう。 技術と人格の役割は何ですか？ たぶん、テキストメールは本当に複雑なプロジェクトを調整するのに最適な方法でしょうか？

gitへの長い道のり

それがすべて始まった方法を思い出してください。 1991年8月25日、未知のフィンランドの学生がcomp.os.minixニュースグループに手紙を書き、そこで彼は無料のオペレーティングシステムと彼の仕事の完了を発表しました。 その年の10月に、彼はLinuxディレクトリのftpにバージョン0.0.2を投稿し、ハッカーの仲間にそれについて通知し、それが始まりました...

開発は当初から、愛好家の分散チームによって行われました。 最初に、Linus Torvaldsはすべてのパッチをチェックし、書き直して、自分でインストールしました。 チームが成長し、パッチがますます増え、コアが成長し、より複雑になりました。 多くの場合、変更を加えずに、パッチを急いで配置する必要がありました。 この状況では、Linusは唯一の正しい決定を下しました 。 成功した人に作業を委任し、信頼することです。 このプロセスは、 Linusがスケーリングしないことで知られる手紙をよく示しています。 再起動 オーバーロードし、さまざまなカーネルサブシステムのメンテナーを割り当てることを提案します。

Linusはスケーリングしません。現在の対処方法は、彼に提出されたパッチの大部分を静かに床に落とすことです。 ほとんどの場合、このコードがドロップされても判断は行われません。 コンパイルエラーを修正するパッチは削除されます。 Linus自身が指定したサブシステムメンテナーからのコードは削除されます。 ツリーのビルドは、かつては警告がなかったときに、簡単に修正可能な多数の警告を吐き出します。 完成したコードは、コードのメンテナーがうんざりするまで、定期的に新しいツリーに対して繰り返し再同期および再差分され、数か月間、定期的に統合されません。 これは、開発者、ユーザー、ベンダーにとって非常に苛立たしいものであり、メンテナーを使い果たしています。 それは不必要な作業の巨大な源です。 状況を解決する必要があります。 速い。

実際、プロジェクトの開発の歴史全体がこのスキームに適合しています。 Linusは次第にコーディングを減らし、プロジェクトの作業を調整するようになり、徐々にハッカーからアーキテクトに変わりました。 これは内部摩擦と粗さなしでは起こりませんでしたが、動きは続きました。 同時に、上級開発者のバックボーンが形成され、コラボレーションのスタイルが形作られていました。 電子メールは当初から共同作業の主要なツールだったため、プロジェクトにいた全員が電子メールでパッチを送信するようになり、ドキュメントに正しく修正する方法を記録することさえできました。

 -rw-r--r-- 1 root root 36604  11 2016 /usr/src/linux/Documentation/SubmittingPatches -rw-r--r-- 1 root root 11186  11 2016 /usr/src/linux/Documentation/email-clients.txt 

それにもかかわらず、2000年までに、バージョン管理システムが必要であることが明らかになりました。 人々は、 Linusが働いた機械的な方法のために開発が遅くなったと不平を言い始めました。 これは事実であり、その後、チームはBitKeeperを採用しました。BitKeeperは 、当時オープンソースの開発者に無料で提供されていたクローズドソフトウェア製品でした。 Linusにとっては実用的でしたが、チームには、少なくとも1バイトのクローズドコードを含むすべてのものをたゆみなく釘付けにする準備ができていたRichard Stallmanの声に耳を傾けない原則のある人が含まれていました。 Alan Cox-カーネルの最初のまともなネットワークスタックを書いたプログラマーもその一人です。

しばらくの間、すべてが順調に進んでいるように見えたが、 BitKeeperは開発者のBitKeeperを楽にしました。 彼らはもはや誰に変更の権利があるのか​​を心配する必要がなく、それぞれがソースツリーの独自のブランチで動作することができます。ソースコードの分散マージ^[2]の可能性は、すべての人に大幅なコスト削減をもたらしました。 それを超えて、危機は醸造され、それがGitの創造につながりました。

それから、 Samba Tridge（Andrew Tridgell）の作者は、他の人よりも良い方法を知っていたこと-リバースエンジニアリング^[3] BitKeeperをしたかったのです。 対立は燃え上がり、ライナスはそれを消そうとしましたが、成功しませんでした。 そして、彼は1日でGitました。 次に起こったことは誰もが知っていることです。VCSのような繊細で保守的なソフトウェアセグメントでは、 Git はわずか数年で競合他社を追い越しました。

主な利点は、幅広い可用性です。

最近、カーネルの安定したLinuxブランチのメンテナーであるGreg Croa-Hartmanが会議で講演し、テキスト電子メールと、共同開発システムの使用、 GitHubやGerritなどのソースコード検査に対する反対意見を述べました 。

GitHub開発者の間で非常に人気にしている明らかな利点を挙げた後、スピーカーは小規模なプロジェクトには最適ですが、規模が大きくないため大規模なプロジェクトには適さないと何度か強調しました。 この点を証明するために、彼はKubernetesを引用し、4,600件のオープンリクエストと約600件のプルリクエストがありました。 プレゼンテーションでは、これらの数値は10％減少しました。

Githubに対する他のGKHの主張：

• インターネットへの常時アクセスが必要ですが、すべての開発者がインターネットにアクセスできるわけではありません。
• プルリクエストとメールを自分でプルします。
• 内部監査の実施は困難です。
• UIに対するクレームは、アプリケーションを追跡するのが非常に困難です。

しかし、スピーカーはいくつかの問題を徐々に解決するように何度か予約し、サービスは常に改善されています。 Greg自身がGithubでusbutilsをホストしています。

ソースコードの共同開発と検査のための残りのシステムは非常にGerritでしたGerritを使用するための唯一の議論は、彼がプロジェクトマネージャーのお気に入りだったという事実だけでした。 当然のことながら、テキストメールが最も賞賛されました。 メールの論文は次のとおりです。

1. シンプルさ
2. 最も幅広い視聴者
3. 拡張性
4. コミュニティの成長を促進する
5. 問題のない内部チェック
6. テキストのローカライズと翻訳
7. パッチの概要
8. リモート検証機能
9. プロジェクトマネージャーの不足

最初の3つのポイントは、実際には同じことの異なるファセットです 。 電子メールはシンプルで、誰もがアクセスできます 。 GKHによると、視覚障害者にとって、このプロジェクトには多くのクールな、しかし盲目のプログラマーがいます。電子メールは利用可能で、WWWは利用できません。 企業のファイアウォールに座っている人には、 git利用できません。また、電子的なファイアウォールにgit問題はありません。 メンテナーは頻繁に旅行し、confで実行します パスワードと出席を変更する Gerritでアプリケーションのステータスを確認する時間と場所を見つけるよりも、インターネットへの接続を待って手紙をダウンロードして送信する方が簡単です。 誰かが長い間アフリカを自転車で移動し、それでもスケジュール通りにパッチを送信しました。

4番目のポイントも非常に重要です。 毎週1〜2回、新人がGKHの視界に入ります。 彼は通常、メーリングリストに参加して、何が起きているのかを印象づけ、詳細を掘り下げるために、読み取り専用モードで1週間だけ滞在することを勧められます。 これは、重要なトピックを二次的なトピックと区別し、議論された問題の深さと詳細を明らかにするための非常に良い方法です。 同時に、そこのどこかでフォーラムを読むために初心者を送ると、誤解とresみに会う可能性があります。

Linuxを管理および開発するための主要なツールとしてプレーンテキストの電子メールを使用することの不利な点について、さらに詳しく見ていきましょう。

私はたくさんの手紙を受け取ります

それがグレッグのブログエントリの名前であり、そこで彼は電子メールで就業日について語っています。

全体として、24時間で2067個の個別のメッセージで18,799,115バイト（18Mb）のメールを受信しました。

これらのうち、メーリングリストへの少なくとも237通のライブレター、Gregはそれらすべてを読みます。

投稿されたすべてを読んだメーリングリストへの237通の電子メール。 これには、多数のopenSUSEメーリングリスト、systemd、linux-usb、linux-pci、linux-hotplug、IP、およびその他のさまざまなトラフィックリストが含まれます。

すべてのメンテナーの中で、彼は最大の負荷と署名されたコミットの数を持っています。

さらに、これらの数は常に増加しています！ どうやらGKHはうまくスケーリングします。

モデルパッチの外観はDocumentation/SubmittingPatches記載されています。 MIMEなどのナンセンスはなく、プレーンテキストのみです。 パッチはレターの本文に含める必要があり、添付しないでください 。

 6) No MIME, no links, no compression, no attachments. Just plain text. ----------------------------------------------------------------------- Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel developer to be able to "quote" your changes, using standard e-mail tools, so that they may comment on specific portions of your code. For this reason, all patches should be submitted by e-mail "inline". WARNING: Be wary of your editor's word-wrap corrupting your patch, if you choose to cut-n-paste your patch. Do not attach the patch as a MIME attachment, compressed or not. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. A MIME attachment also takes Linus a bit more time to process, decreasing the likelihood of your MIME-attached change being accepted. Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME. See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched. 

難しいことではないように見えますが、実際には、すべてのメールプログラムが管理しているわけではありません。 主な新製品のMS Outlook、Gmail（Web UI）、Lotus Notesがあります。

 (5:534)$ grep -A2 Lotus /usr/src/linux/Documentation/email-clients.txt Lotus Notes (GUI) Run away from it. 

それらを使用する企業には、パッチを送信する専用のLinuxワークステーションが常にあります。

とりわけ、16のルールの中で、メッセージの件名と内容の形式が明確に定義されています。

 The canonical patch subject line is: Subject: [PATCH 001/123] subsystem: summary phrase The canonical patch message body contains the following: - A "from" line specifying the patch author (only needed if the person sending the patch is not the author). - An empty line. - The body of the explanation, line wrapped at 75 columns, which will be copied to the permanent changelog to describe this patch. - The "Signed-off-by:" lines, described above, which will also go in the changelog. - A marker line containing simply "---". - Any additional comments not suitable for the changelog. - The actual patch (diff output). 

多くの場合、手紙には奇妙な事件が起こります。 Linusは、このコピーペーストがゴミを出すため、スペースとタブを損なうため、Dmitry TorokhovのKMailを地獄に焼き付けなければならないと文句を言います。

あなたのタブとスペースはタブとスペースではなく、恐ろしい忌まわしいものだからです。

上記のタブのように見えるものを保存して「od」で見ると、それは本当の厄介な生活を示しています。タブではなく、8個のスペースでもなく、バイトシーケンスの4つのコピー '\ 302 \ 240 '（' \ xC2 \ xA0 \ x20 '）、つまり、1つの文字がスペースで、前の2つの文字がutf-8の憎悪である、恐ろしい厄介な3バイトシーケンスです。

しかし、 Linusは 、スパムボットが20％のケースで台無しになるという事実に対するGMail テクニカルサポートを報告しています。

プログラマーとメンテナーの間で理解の問題がまだあるかもしれません。 翻訳におけるLWNの解説。

電子メールのパッチをチェックすることは、push --forceと比較して面倒です。 処理中の応答でパッチの1つのv2を送信するとメンテナーは不平を言いますが、逆に、代わりに1つのブロックで新しいv2全体を代わりに送信すると不平を言いますか？ 必要なものを適用するためにv2に気づくでしょうか、プルリクエストのステータスを変更することはできません。 メンテナーとして、同じ状況で調整を正しく適用できますか？

一般的なバランスと結論

ライナスと彼の同志が1990年代の古い習慣を標準化したという印象から逃れることは難しい。 これは主観的な要因ですが、客観的な要因にもかかっています。 25年前にLinuxカーネルを作成したハッカーは、オープンソースコミュニティが物質的な力と道徳的リーダーシップを獲得したおかげで、この方法で大きな利益を得ることができます。 才能のある卒業生[バウマンモスクワ州立大学MIT Berkeley your_love_VUZ]を採用し、メンテナー全員を完全に置き換えると、1年か2年後に彼ら自身がGitHubに行くか、自分で何かを書き、スライドで生産性がどれだけ向上したかを証明します。 証拠は、テキスト文字の本文にパッチなしで静かに作成する比較的大規模なプロジェクトの存在です。 また、Google は Gerritを使用してAndroidを開発しています。

要約として、私はLWNに関するコメントを提供します。

私の論文によると、90年代には、オープンコミュニティには協力のための最高のソフトウェアツールがあり、これが私たちが成功した理由です。 その後、所有者は私たちに追いつき、私たちを上回った。 ツールキットに再度投資して更新するか、成功を続けたい場合は少なくともそれらのサンプルを採用する必要があります。

そして、Habrはこれについてどう思いますか？

使用材料

1. カーネル開発がまだ電子メールを使用する理由
2. Gitの10年：Git作成者Linus Torvaldsへのインタビュー
3. GKHプレゼンテーションスライド

---

1. ↑ githubやgerritなどの「最新の」開発ツールの豊富な選択肢があるのに、1990年代にLinuxカーネルプログラマーは、単純なテキストメールメッセージの本文にパッチルールが詰まっているのはなぜですか？ カーネルの開発がどのように行われるか、なぜ「古代の」ツールに依存するのか、そしてそれらが他の誰よりも優れているのかを学びます。 GKHの発表ページから、
2. ↑分散マージ。
3. ↑リバースエンジニアリング。