6: フォロースルー

この段階になると、これまでに説明したガイドラインに従い、また自分自身の設計スキルを活用し、完全なパッチ群をポストしたことになります。経験の深いカーネル開発者でさえ犯してしまうことがある最大の間違いのひとつは、この段階で自分の作業は完了したと結論付けてしまうことです。実際には、パッチのポスト全体プロセス中の次の段階への移行のみを示すものであり、その後に行うべき作業もおそらく相当に多いものと考えられます。

最初のポスト時から非常に優れており、その後の改良の余地がないようなパッチは稀です。カーネル開発プロセスではこの事実がよく認識されているため、ポスト後のコードの改良に向けた動きに重点が置かれています。そのコードの作者には、カーネルの品質基準が満足されるまで、カーネル・コミュニティとの共同作業に参加することが期待されます。このプロセスに参加しなかった場合、そのパッチがメインラインに含められなくなる可能性が非常に高くなります。

6.1: レビューアとの共同作業

何らかの重要性があるパッチの場合、コードをレビューした他の開発者からのコメントが多く寄せられます。多くの開発者にとって、これらレビューアとの作業がカーネル開発プロセスの中でも最もフラストレーションが大きい部分です。ただしいくつかの点に留意することで、このフラストレーションは相当に軽減されます。

• そのパッチについて十分な説明があれば、レビューアはそのパッチの価値や、その困難なパッチ作成に至った理由を理解してくれます。しかし、その価値が理解されただけでは、「このコードを含めたカーネルを5～10年後に保守する場合はどうなるか？」という彼らの基本的な質問を抑えることはできません。コーディング・スタイルの調整から大幅な書き直しまで、多くの変更が要請される可能性がありますが、これらはいずれもLinuxは10年後にも使われており、開発が継続されているだろうという認識に基づくものです。
• コード・レビューは骨の折れる、比較的感謝されることの少ない仕事です。カーネル・コードを作成した人は記憶されますが、そのレビューを行った人の名声が長く続くことはほとんどありません。そのためレビューアは、特に同じ間違いを何度も繰り返された場合など、機嫌を悪くしてしまう場合があります。怒り、侮辱、あるいは明らかな攻撃に満ちたレビューを受けた場合は、同様の方法で応酬したいという衝動にかられるかもしれません。しかしじっと耐えてください。コード・レビューはあくまでコードに対するレビューであり、人に対するものではありません。またレビューアは個人的な攻撃を行っているわけでもありません。
• 同様に、コード・レビューアは、レビュー対象者を食い物にして彼らの企業方針を推進しようとしているわけでもありません。カーネル開発者は今後何年間もカーネル開発に取り組むことを期待している場合が多いですが、同様にその雇用主が変わってしまう可能性についても承知しています。彼らは本当のところ、ほとんど例外なく、可能な限り最善のカーネルを構築するために働いており、その企業の競争相手を苦しめようとしているわけではありません。

すなわち、これらのことを総合して言えば、レビューアからのコメントを受けた場合、その技術的な意見に注意を払う必要があるということです。彼らの表現スタイルや自分自身のプライドのために、このことがおろそかにならないようにして下さい。パッチに対するレビュー・コメントを受けたら、時間をかけてそのレビューアが言いたいことを理解してください。可能であれば、そのレビューアが望む修正を行ってください。それからレビューアに回答し、感謝を述べ、彼らの質問にどう対応するかについて説明してください。

なお、レビューアから提案された変更のすべてに同意する必要はありません。そのレビューアが自分のコードを誤解していると考えられる場合、実際に行っていることを説明します。提案された変更に対し技術的に賛成できない場合はその内容を説明し、問題に対する自分の解決策を正当化します。その説明が道理にかなったものであれば、レビューアはその内容を受け入れます。自分の説明に説得力がなく、また特に他の参加者もレビューアに賛成し始めた場合には、少し時間をおいてもう一度考え直してみてください。何かが基本的に間違っていることや、自分の解決策が真の問題を解決してないことに気が付かなくなることもあります。このように問題に対する自分の解決策に固執するあまり盲目になってしまうことはよくあることです。

決定的な間違いは、そのコメントがなくなることを期待してレビュー・コメントを無視することにあります。コメントが消えることはありません。以前に受けたコメントに対する回答を行わずに再びコードをポストした場合、おそらく何も先に進まなくなることがわかります。

コードの再ポストについて言えば、レビューアは前回ポストされたコードの内容をすべて記憶していることはないと考えておいてください。そのため、以前に出た問題をレビューアに思い出させ、それに対しどう対処したかを説明する方がいいでしょう。パッチの変更履歴はこの種の情報を示す良い場所になります。前回の議論の内容を思い出すためレビューアがメーリングリストのアーカイブを検索しなければならないような状況は好ましくありません。彼らが直ちにスタートできるよう準備しておけば、彼らは気分良くコードの再検討ができるようになります。

やるべきことはすべて実行したのに、依然として先に進まない場合はどうでしょうか？ほとんどの技術的な不一致は討論を重ねることで解決しますが、誰かが決定しなければならない時があります。その決定が自分にとって不当なものだと正直に信じられる場合、より上位に位置する権威者に訴えることができます。この文書の作成時点における上位の権威者とは、Andrew Mortonのことです。Andrewはカーネル開発コミュニティの尊敬を集めており、ほとんど絶望的に行き詰まった状況を打開できる場合も多くあります。ただしAndrewへの支援要請は軽々しく行われるべきではなく、あらゆる代替案の追求が終わるまで待つことが必要です。また、彼も自分の意見に同意してくれるとは限らないということを念頭に置いてください。

6.2: 次に何が起きるか？

そのパッチのカーネルへの追加が望ましいものと考えられ、またすべてのレビュー問題が解決した場合、次のステップは通常、メンテナーのツリーへの追加となります。その方法はサブシステム毎に異なり、メンテナーがそれぞれ自分自身の方法を用いています。特に、ツリーが二つ以上用意されている場合もあります。この場合、おそらくひとつは次回のマージ・ウィンドウに予定されるパッチ専用のツリーで、もうひとつは長期的な作業に用いるものとなるでしょう。

明確なサブシステム・ツリーの存在しない分野のパッチ（たとえばメモリー管理のパッチ）の場合、そのデフォルト・ツリーは最終的に -mmツリーとなる場合が多くなります。複数のサブシステムに影響するパッチも最後は -mmツリーに落ち着く場合があります。

サブシステム・ツリーに含めることにより、そのパッチの可視性が向上します。この段階では、そのツリーに関係する他の開発者はデフォルトでそのパッチを入手することになります。通常、各サブシステム・ツリーは -mmやlinux-nextにも接続されており、その内容が開発コミュニティ全体から見えるようになります。この時点で、再び別のレビューア集団から追加コメントを受ける可能性がかなりありますが、これらのコメントについても前回と同様に回答することが必要です。

この段階で更に発生する可能性があることは、そのパッチの性質により、他の開発者が行っている開発との競合が見えてくることです。最悪のケースとしてパッチの競合の度合いが非常に大きい場合、一部のパッチを棚上げとし、残りのパッチを統合して機能させるといった結果になることもあります。また別のケースとして、競合の解決のため別の開発者と共同で作業を行い、すべてが明確に適用できるよう、場合によっては一部のパッチをツリー間で移動する場合もあります。このような作業は苦痛ですが、それでも以前に比べれば恵まれています。すなわち、linux-next ツリーが実現する前はこのような競合が判明するのはマージ・ウィンドウ期間中であり、短い時間での素早い対応が必要でした。今ではマージ・ウィンドウが開くまでの間、時間的な余裕を持って解決にあたることができます。

すべてがうまく行けば、いずれは自分がログオンした時、自分のパッチがメインライン・カーネルにマージされていることを確認できます。おめでとうございます（MAINTAINERSファイルに自分の名前が追加されます）。ところで、お祝いが終わったところで、小さなことですが、ひとつ重要なことを覚えておくことが必要です。つまり、仕事はまだ終わっていないということです。すなわち、メインラインにマージしたことによる課題が発生します。

まず、自分のパッチの可視性がさらに向上しました。このパッチにこれまで気付かなかった開発者達からのコメントが新たに寄せられる可能性があります。自分のコードのマージについて心配する必要はもうないため、そのようなコメントは無視したいという誘惑に駆られるかもしれません。しかし、そのような誘惑は捨ててください。自分には質問や提案を寄せる開発者達に対し敏感に対応する責任があります。

しかし更に重要なことは、自分のコードがメインラインに含まれたことにより、そのコードがより大きなテスターの集団の手に渡ったということです。まだ利用可能になっていないハードウェア用のドライバを提供した場合でさえ、驚くほど多くの人がそのコードを自分のカーネルへとマージします。そして、当然のことですが、バグ報告も送られてきます。

バグ報告のうち、最悪のものはリグレッションの報告です。そのパッチでリグレッションが発生した場合、不快なほど多くの視線が自分に注がれることがわかります。リグレッションについてはできるだけ早急な修正が必要です。自分がその修正に不賛成、またはそれが不可能な場合（または誰も修正してくれない場合）、そのパッチはほぼ間違いなく安定化期間中に削除されます。パッチをメインラインにマージするために行ったこれまでの自分の努力がすべて否定されるだけでなく、リグレッションを解決するための修正ができずにパッチが削除されたという事実は、将来的に自分の成果物をマージしようとした場合それが困難なものとなってしまう可能性があります。

リグレッションへの対応が完了しても、それとは別に通常のバグ対応も必要となる場合があります。安定化期間は、これらのバグ修正を行い、メインライン・カーネル・リリースに向けての自分のコードのデビューを可能な限り確実なものにするための最適な機会です。そのため、バグ報告に回答するとともに、可能な限り問題の修正を行ってください。安定化期間はそのために設けられています。そのパッチへの対処が完了すれば、新たに素晴らしいパッチの作成を開始することができます。

また、次回のメインラインの安定リリースや有力なディストリビュータが自分のパッチを含むカーネルのバージョンを採用したときなど、新たなバグが報告される可能性もあります。このような場合のマイルストーンについても忘れないようにしてください。そのような報告への対応を継続することは、自分の仕事に対する基本的なプライドの問題です。もしそれだけでは動機付けが不足する場合、マージ後の自分のコードに対し関心を失ってしまうような開発者はそのように開発コミュニティに記憶されてしまうということを理解しておいてください。次にパッチをポストしたとき、彼らは作者によるマージ後の保守対応が行われないという前提でその評価を行うでしょう。

6.3: 起きる可能性のある出来事

ある日メール・クライアントを開くと、誰かが自分のコードに対するパッチを送付してきたことに気付くかもしれません。これは、結局のところ、自分のコードを公開したことによる利点のひとつです。そのパッチに同意した場合、自分でそのパッチをサブシステムのメンテナに転送するか（この場合、その帰属を示すための適切な「From:」行を追加し、自分のサインオフを追加します）、または「Acked-by:」応答を返し、そのポスト元にその先の提出を行わせることができます。

そのパッチに同意できない場合は、その理由を説明した礼儀正しい回答を送ります。可能であれば、そのパッチを自分が承認するためにはどのような変更が必要かをその作者に説明します。コードの作者およびメンテナーが反対するパッチをマージすることには一定の抵抗がありますが、それ以上ではありません。優れた成果を原作者が不必要に妨害していると見られた場合、そのようなパッチは最終的には先の過程へと流され、いずれはメインラインにマージされます。Linuxカーネルにおいては、いかなるコードについても絶対的な拒否権を持つ人はいません。ただし、おそらくLinusは別でしょう。

非常に希なケースとして、上記にはあげなかったまったく異なった状況に遭遇する場合も考えられます。すなわち、自分が解決した問題に対し、別の開発者が別の解決策をポストした場合です。この時点で、おそらく二つのパッチのうちひとつはマージされなくなると考えられます。また「自分の方が先だった」という主張は、技術的には説得力がなく考慮されることはありません。自分のパッチが他人のパッチで置き換えられてメインラインにマージされた場合、それに対する反応はまさにひとつだけです。すなわち、その問題が解決されたことに満足し、自分の仕事を続けていくことです。このような形で自分の成果が脇に押しのけられてしまうのはフラストレーションであり、落胆もありますが、コミュニティは、誰のパッチが実際にマージされたかを忘れてしまった後でも、その作者の対応はずっと覚えていてくれます。