OLS：カーネルの文書についての講演とカーネルパッチの提出についての講演
Landley氏は昨年、Linuxカーネルの文書を向上させるためのLinux Foundationの半年間のフェローシップを受けた。Landley氏の説明によると当初は一年間の予定だったのだが、6ヶ月が経過した時点で文書のために行うべき事についてある結論に達して、Linux Foundationもその結論に同意した上で継続はしないということに決めたため、Landley氏は他のプロジェクトのメンテナの作業に戻ったのだという。
「カーネルについての文書はどこにあるのだろうか？」とLandley氏は問いかけた。そしてカーネルについての文書は、カーネルのtarファイル、ウェブ、雑誌、OLSのようなコンファレンスの議事録、manページ、メーリングリストのアーカイブ、開発者のブログなどの中にあるとして、さらに「それらも氷山の一角に過ぎない」と付け加えた。つまり問題なのは文書が存在しないことではなく、存在しているものがインデックス化されていないということなのだという。
したがってLandley氏は、Linuxカーネルについての文書の提供に関して何か役に立つことをしよう思うのならば、取り組むべきは既存の文書をインデックス化する作業だとした。あるテーマについての何らかの情報源が十分な影響力を持つと、その情報源はカーネルの特定のサブセクションの情報源としてのデファクトスタンダードになって、それ以降はよく知られるようになり保守されるようになる。しかしそのような情報源は散在しているので、統合的に整理するという作業が大きな問題になる。
Linuxカーネル開発者たちにとって、Linuxカーネルメーリングリストの全内容を遅れずに追い掛け続けることはおろか、他のすべてのメーリングリストに目を通したり、増え続ける文書を次から次へと読んだりすることは非常に困難なのだという。インターネット上で見つけることのできるカーネル文書すべてを整理するという作業も、すでにそれ自体がフルタイムの仕事量に値する。例えばLWNのJonathan Corbet氏が優れた仕事をすでに行っているほかにも、各領域で独自の方法で行っている様々な人々がいるという。
またLinuxカーネル開発者のブログのアグリゲータであるkernelplanet.orgや、その他のアグリゲータからも大量の情報を得ることができるものの、Landley氏は「アグリゲータのアグリゲータ」が必要になっているとした。このような問題のためにはGoogleは不十分で、ちょっとした情報を見つけるために30分もかかることがあり、また見つけることができるとしてもgoogleで見つけることができるのはウェブページだけであり、例えばカーネルのソースtarファイルの中のDocumentationディレクトリの中まで検索できるわけではないのだという。
ではどうすれば解決できるのだろうか。Landley氏は、kernel.org内に新設したkernel.org/docというページの仕組みを説明した。このページでは、収集された文書がすべてMercurialのアーカイブに保存され、機械的にインデックス化されている。このデータベースに情報を追加するにはかなりの編集作業が必要になるが、このことについてLandley氏は「メンテナの仕事はノーという言葉を言うことだ」というAlan Cox氏の言葉を引用した。Landley氏は、kernel.orgのカーネル文書メンテナとしての自らの主な仕事は、カーネルパッチの場合とちょうど同じように、提出されたものを却下することだと考えているのだという。また文書はそれだけで一ツリーとして、常に更新/保守される必要があるとのことだ。
kernel.org/docのような仕組みを採用しWikipediaを使用しなかった理由を訊ねられてLandley氏は、Wikipediaでは却下することができないので提供する情報についての実質的な品質管理が行われないためと、（今も解決していないWikipediaの核心的な問題点として）インデックス化のための合理的な仕組みがないためだと答えた。
Landley氏のLinux Foundationでの半年間は今から10ヶ月前に終了した。Landley氏は現在もメンテナを務めているものの、保守を続けるための時間の確保が難しくなってきていることから、十数人規模の一プロジェクトとしてメンテナの下でカーネル文書を扱う専任のボランティアグループが現実的には必要となっていると訴えた。
カーネルの機能の提出について
今日出席した中でもう一つ、興味深いがやや難解でもあったのは、Andi Kleen氏による「On submitting kernel features（カーネルの機能の提出について）」という短い講演だ。
Kleen氏は「パッチを提出するのはなぜか？」と問いかけて、人々がカーネルパッチを提出する理由は様々だとした。パッチを提出すれば、その結果としてコードがレビューされて、通常はコードの品質が向上する。またカーネル内にコードが統合されれば、無料でユーザによるテストが行われる。カーネルと別に存在するのではなくカーネル内に統合されているコードには、ユーザインターフェース上の衝突がなくなる。またその機能が広く使われるようになれば、無料で他のアーキテクチャに移植されることになる。つまりKleen氏によれば、コードがカーネルに統合されることは、変更を配布するための最良の方法なのだという。すなわち一度メインラインカーネルに入ってしまえば、あらゆる人々に使われることになる。
では、どうやってコードをカーネルに統合させれば良いのだろうか？
Kleen氏は、カーネルに機能を提出するための簡単なプロセスをいくつか概説して、分かりやすくするために2つの事例を挙げた。基本的なプロセスとしては、次のような筋書きを説明した。
開発者がコードを書いてテストする。そしてレビューを求めて提出する。その後レビューから得られたフィードバックに基づいて、必要に応じてコードを修正する。コードは、提出されたパッチのカーネルでの該当分野の担当メンテナによって、カーネルの開発ツリーに統合される。そしてコードは開発ツリーにおいてテストされる。その後カーネルに統合されて、そのカーネルがリリースされる。
コードを提出する際に覚えておくべき基本的なこととして、コードのスタイルが正しく、カーネルのソースtarファイルの中のDocumentationディレクトリにあるCodingStyle文書に従っている必要があるということがある。また提出されたパッチはちゃんと動作し、文書化されていなければならない。開発者は、必要に応じて改訂やアップデートが行われるのにともなって、コードのための作業がさらに必要になることを覚悟しておく必要がある。また批判されることも覚悟しておくべきなのだという。
Kleen氏は、カーネルのコードを提出することを学術論文の出版のために学術雑誌に提出することになぞらえた。自分のカーネルパッチに注目してもらうためには、そのパッチをうまく売り込む必要がある。概してレビュアーの人数は不足していて、メンテナは多忙であることが多い。また場合によっては、はっきりとしたメンテナが存在しない分野にパッチを提出することになることもある。そのため統合プロセスを始めるために必要なレビューアを獲得するためには、パッチをうまく売り込む必要がある。
Kleen氏によれば、必要なのは機能を売り込むことであり、また問題を抱える部分があれば可能な限りその部分を切り離してしまうべきだという。また再設計が必要な場合には早めに再設計を行うようにすべきだという。さらに最初から全機能を提出しようとするべきではないという。Kleen氏は事例研究として同氏が書いたdprobesというシステムを紹介した。 提出後しばらく経ってもうまく行きそうになかったため、パッチの設計をずっとシンプルなものにして、機能数を減らして、kprobesと名称変更して再提出したところ、すぐに採用されたのだという。
一方、機能の追加ではなくコードの修正の場合にはいくつかのタイプがあるという。明らかなバグ修正はもっともやりやすく、また売り込みもうまく行く。一方Kleen氏によればコードのクリーンナップのやり過ぎは勧められないとのことだ。バグ修正の方がそれよりも重要だからなのだという。また最適化については、「どれほど役に立ちそうだろうか？」、「カーネルの負荷にどれほどの影響を与えるだろうか？」、「全体としてコードがどれほど複雑になるだろうか？」など、いくつかの問いをまず自分自身に問いかけることを勧めた。
Kleen氏は、パッチの提出は実質的に論文の出版と同じことだとした。そのためパッチの説明文は重要で、簡潔な紹介文も添えるようにするべきだという。また英語を書くのが苦手な場合は、紹介や説明を書く手助けを求めるように勧めた。
時間をかけてパッチ数をこなせば、統合までの作業は次第に容易になってくるという。メンテナが開発者のパッチを承認するということは、メンテナが開発者を信用するということだ。そして信用は、時間をかけて築かれるものなのだ。Kleen氏はパッチ開発の際にカーネルメーリングリストを活用することと、信用を構築するためにパッチとは直接関係のないクリーンナップやバグ修正にも取り組むことを勧めた。
Kleen氏の講演内容は同氏のウェブサイトで公開されている。
