初めに
以下の訳文です。カーネルレシピのGreg Kroah-Hartmanの話のJonathan Corbetによる要約です。ライセンスは原文に準じます。
https://lwn.net/Articles/702177/
(LICENSE: https://creativecommons.org/licenses/by-sa/4.0/)
- 見出しは内容の整理のために訳者が勝手に付加したものです。
- ご指摘等ありましたらコメント、編集リクエストでどうぞ。
参考：
パッチ投稿のフローについては同じGregによる以下の記事（翻訳）が詳しいです。
http://blog-ja.intransient.info/2010/09/linux.html
なぜカーネル開発ではいまだにEmailを使うのか？
古臭い遺物?
世の中には見栄えの良い開発ツールやサイトが溢れていますが、カーネルプロジェクトはEmailやメーリングリストに依存しており、懐古趣味に積極的でもなければ古臭く取り残されているだけに思えるでしょう。しかしながら、グレッグ クロー＝ハートマンが Kernel Recipes talk の中で取り上げた「Patches carved into stone tablets(石板に刻まれたパッチ)」と題する話の中で、カーネルコミュニティのその選択にはいくつかの良い理由があると述べています。古い時代の遺物なのではなく,むしろEmailはカーネルのような巨大なプロジェクトを管理するのに最適なツールとして生き残っているのです。
カーネルプロジェクトの規模
手短に言いますと、グレッグは「カーネル開発者たちはいまだにEmailを使っている。他の方法よりも高速だからだ」と述べています。昨年１年間で、カーネルプロジェクトは400以上の企業によって支えられる4000人の開発者たちから1時間（毎時です）に8件の変更を受け付けました。物事は正しく行われているに違いありません。１日に少なくとも１つのパッチを受け入れたメンテナのリストには75人のエントリがあり、そのリストのトップにグレッグがいるわけですが、グレッグ自身は9781のパッチを昨年一年間に受け付けました。実際に受け付けられるのは1/3程度であることを考慮すると、パッチの投稿率はそれよりかなり高いことは明白です。
このようなパッチの投稿率を管理できるツールを探すのは大変です。グレッグは「下手な職人は道具の文句を並べ立て、腕の立つ職人は良い道具の探し方を知っている」と述べます。
Githubはどうか？
利点
では開発に役立つツールは何でしょうか。グレッグはGithubから着目しました。グレッグはそれにはたくさんの利点があると述べます。とっても素敵で、小さなプロジェクトで使用するのが容易で、シンプルなインターフェースはありがたい、とグレッグは述べます。Githubはフリーで帯域制限なしですし、お金を払えば企業のインフラとして運用する事もできます。単発的なパッチの作者たちにとってそれは生きるのを容易にしてくれます。グレッグもusbutilsプロジェクトで散発的なパッチを取得するのにGithubを使っています。
問題
一方、Githubは大きなプロジェクトにはスケールしません。彼は4000のイシューと511のプルリクエストを持つKubernetesプロジェクトについて触れました。Githubのシステムはレビュアーが大勢いる場合にはうまく機能しないとグレッグは述べます。Githubにはプルリクエストに付随した議論のためのスレッドの合理的なメカニズムがあります。Githubはこの特徴のためEmailを複製しますが、しかしそのスレッドは実際にそのプルリクエストに割り当てられた人たちしか見ることができません。
また、GitHubではオンラインのアクセスが必要ですが、たくさんのカーネル開発者たちは、理由は様々ですが作業中にネットへの良いアクセスがありません。一般的には、良くなりつつありますが、Kubernetesのようなプロジェクトはスケールにもっとあったものを探す必要に気づいています。カーネルにおいては、上手くいかないでしょう。
Gerritは・・・
実態
話はGerritに移ります。グレッグはGerritの利点を列挙し始めましたが、少し休止して、「何も知らなかった」と述べました。実際には、この点です。プロジェクトマネージャ達はGerritを愛しています。グーグルはAndroidプロジェクトでGerritを使用するように促しましたが、グーグルの社内プロジェクト、Androidのプロジェクトでさえも使用していないのです。Gerritは実際には必要とされていないのです。グレッグはこの点を指摘しました。Androidにおいてパッチを取得する込み入ったフローチャートの中で、Gerritは小さくて代替可能な位置づけでしかないのです。
問題
Gerritは、パッチの提出をきわめて困難にします。Repoはその点で少しは助けになるかもしれませんが、使用しているプロジェクトはそんなに多くはありません。Gerritはスクリプトで書くことができますが、そうしているのは少数の人々だけです。聴衆の一人が「Gerritを使用することはパッチを提出するごとに納税手続きをするようなものだ」と飛び入りで発言しました。レビューのインターフェースを見るなら、Gerritを使用する開発者はコードレビューには実際に時を費やしていないことは明白です。彼は特にパッチが当てられた全てのファイルを閲覧する際に個別にクリック出来る必要性を指摘しました。Gerritではローカルテストを実施するのが困難であり、一つのパッチのシリーズを追跡することは不可能です。全ての議論はウェブインターフェースを通して行われます。仕事の一部でもなければ誰もレビューはしないでしょう、とグレッグは述べます。
やっぱりplaint text Email
汎用性
ではプレーンテキストのEmailについてはどうでしょうか。Emailは永遠に私たちの周りにあり、だれでも何らかの形式でアクセス出来ます。フリーメールプロバイダは大量にありますし、クライアントも莫大な数があります。Emailはネイティブでない話者、機械翻訳を必要とし使用する人もうまく使うことができます。Emailはアクセシビリティーの点でもフレンドリーで、視力障害を持つ開発者たちを多数取り込む点で貢献してきました。Emailは高速で、ローカルのテストが容易で、離れた場所からテストすることも可能です。Emailパッチを扱うスクリプトを書く作業はたやすくできます。そして作業のために新たなインターフェースを学ぶ必要もありません。
欠点
一方、一概にいってEmailクライアントは出来がよくありません。Outlookのようなシステムではパッチが一様に壊れてしまいます。結果として、カーネル開発を行っている企業はパッチを送るために使用するLinuxマシンをどこかに置く傾向があります[*ジョークだろうか]。Gmailでパッチを送るのは苦労しますが、IMAPサーバとしてはとても優秀に動作します。プロジェクトマネージャはEmailを嫌う傾向にあるようです。いずれにせよカーネルのワークフローには、プロジェクトマネージャが関与することなどないので、Gregはそれを利点だ、悪く取ると[彼らには]無関係だ、と考えているように見えます。
他ツールとの統合
Emailはたやすく他のシステムと統合することができます。それは例えばカーネルの0-dayビルドや起動テストシステムでも上手く機能します。パッチワークシステムからはとてもよくサポートされています。カーネルの数多くのサブシステムの状態を追跡するのにパッチワークシステムは用いられています。パッチワークはメーリングリストを監視し、見つかったパッチを集め、活動を追跡したりします。また、それはプロジェクトマネージャが大好きなステータスリストを提供します。
コミュニティの形成
要約しますと、Emailはシンプルで、最も大きなグループをサポートし、スケーラブルであるという点が重要なのです。しかしもっとも重要なことはEmailがコミュニティを育てることです。新しい開発者たちがやって来る時、一番最初に学ばなければならないのはプロジェクトがどのように機能しているかということです。それは開発者たちが行っているレビューを読むことも含まれます。それは開発者たちが気にかけていること、ミスを避けるために行っていることを学ぶやり方です。カーネルにおいて、レビューはすべてメーリングリスト上で読むことができます。Gerritのようなシステムでは探し出すだけで一苦労です。
Rusty Russelがかつて語ったように、もしもっとスマートになりたいなら、スマートな人たちと関わらねばなりません。Emailベースのワークフローは開発者たちをプロジェクトのスマートな人たちと関わらせ、皆がスマートになります。グレッグはLinuxが長く続くことを望んでおり、そのためにも新しい開発者たちが参入する助けとなるツールをカーネルプロジェクトで使用して欲しいと思っています。Emailは、欠点だらけとはいえ、その点について言えば他のものよりもいまだに優れているのです。
雑感
- 初心者は半年ROMれというコミュニティにおける古の金言を思い出した。
- 視覚障害をもつ開発者たちが大勢いると言う点、彼らに配慮されている(結果的にであろうが)という点に励みを受けた。
- PMをいじめないで、、、