howto

linux 内核源代码

ります-
	http://vger.kernel.org/vger-lists.html

メーリングリストを使う場合、良い行動習慣に従うようにしましょう。
少し安っぽいが、以下の URL は上のリスト(や他のリスト)で会話する場合の
シンプルなガイドラインを示しています-
	http://www.albion.com/netiquette/

もし複数の人があなたのメールに返事をした場合、CC: で受ける人のリストは
だいぶ多くなるでしょう。良い理由がない場合、CC: リストから誰かを削除を
しないように、また、メーリングリストのアドレスだけにリプライすることの
ないようにしましょう。1つは送信者から、もう1つはリストからのように、メー
ルを2回受けることになってもそれに慣れ、しゃれたメールヘッダーを追加し
てこの状態を変えようとしないように。人々はそのようなことは好みません。

今までのメールでのやりとりとその間のあなたの発言はそのまま残し、
"John Kernlehacker wrote ...:" の行をあなたのリプライの先頭行にして、
メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで
す。

もしパッチをメールに付ける場合は、Documentaion/SubmittingPatches に提
示されているように、それは プレーンな可読テキストにすることを忘れない
ようにしましょう。カーネル開発者は 添付や圧縮したパッチを扱いたがりま
せん-
彼らはあなたのパッチの行毎にコメントを入れたいので、そのためにはそうす
るしかありません。あなたのメールプログラムが空白やタブを圧縮しないよう
に確認した方が良いです。最初の良いテストとしては、自分にメールを送って
みて、そのパッチを自分で当ててみることです。もしそれがうまく行かないな
ら、あなたのメールプログラムを直してもらうか、正しく動くように変えるべ
きです。

とりわけ、他の登録者に対する尊敬を表すようにすることを覚えておいてくだ
さい。

コミュニティと共に働くこと
--------------------------

カーネルコミュニティのゴールは可能なかぎり最高のカーネルを提供すること
です。あなたがパッチを受け入れてもらうために投稿した場合、それは、技術
的メリットだけがレビューされます。その際、あなたは何を予想すべきでしょ
うか?
  - 批判
  - コメント
  - 変更の要求
  - パッチの正当性の証明要求
  - 沈黙

思い出してください、ここはあなたのパッチをカーネルに入れる話です。あ
なたは、あなたのパッチに対する批判とコメントを受け入れるべきで、それら
を技術的レベルで評価して、パッチを再作成するか、なぜそれらの変更をすべ
きでないかを明確で簡潔な理由の説明を提供してください。
もし、あなたのパッチに何も反応がない場合、たまにはメールの山に埋もれて
見逃され、あなたの投稿が忘れられてしまうこともあるので、数日待って再度
投稿してください。

あなたがやるべきでないものは?
  - 質問なしにあなたのパッチが受け入れられると想像すること
  - 守りに入ること
  - コメントを無視すること
  - 要求された変更を何もしないでパッチを出し直すこと

可能な限り最高の技術的解決を求めているコミュニティでは、パッチがどのく
らい有益なのかについては常に異なる意見があります。あなたは協調的である
べきですし、また、あなたのアイディアをカーネルに対してうまく合わせるよ
うにすることが望まれています。もしくは、最低限あなたのアイディアがそれ
だけの価値があるとすすんで証明するようにしなければなりません。
正しい解決に向かって進もうという意志がある限り、間違うことがあっても許
容されることを忘れないでください。

あなたの最初のパッチに単に 1ダースもの修正を求めるリストの返答になるこ
とも普通のことです。これはあなたのパッチが受け入れられないということで
は *ありません*、そしてあなた自身に反対することを意味するのでも *ありま
せん*。単に自分のパッチに対して指摘された問題を全て修正して再送すれば
良いのです。


カーネルコミュニティと企業組織のちがい
-----------------------------------------------------------------

カーネルコミュニティは大部分の伝統的な会社の開発環境とは異ったやり方で
動いています。以下は問題を避けるためにできると良いことのリストです-

  あなたの提案する変更について言うときのうまい言い方：

    - "これは複数の問題を解決します"
    - "これは2000行のコードを削除します"
    - "以下のパッチは、私が言おうとしていることを説明するものです"
    - "私はこれを5つの異なるアーキテクチャでテストしたのですが..."
    - "以下は一連の小さなパッチ群ですが..."
    - "これは典型的なマシンでの性能を向上させます.."

  やめた方が良い悪い言い方：

    - このやり方で AIX/ptx/Solaris ではできたので、できるはずだ
    - 私はこれを20年もの間やってきた、だから
    - これは、私の会社が金儲けをするために必要だ
    - これは我々のエンタープライズ向け商品ラインのためである
    - これは 私が自分のアイディアを記述した、1000ページの設計資料である
    - 私はこれについて、6ケ月作業している。
    - 以下は ... に関する5000行のパッチです
    - 私は現在のぐちゃぐちゃを全部書き直した、それが以下です...
    - 私は〆切がある、そのためこのパッチは今すぐ適用される必要がある

カーネルコミュニティが大部分の伝統的なソフトウェアエンジニアリングの労
働環境と異なるもう一つの点は、やりとりに顔を合わせないということです。
email と irc を第一のコミュニケーションの形とする一つの利点は、性別や
民族の差別がないことです。Linux カーネルの職場環境は女性や少数民族を受
容します。なぜなら、email アドレスによってのみあなたが認識されるからで
す。
国際的な側面からも活動領域を均等にするようにします。なぜならば、あなた
は人の名前で性別を想像できないからです。ある男性が アンドレアという名
前で、女性の名前は パット かもしれません (訳注 Andrea は米国では女性、
それ以外(欧州など)では男性名として使われることが多い。同様に、Pat は
Patricia (主に女性名)や Patrick (主に男性名)の略称)。
Linux カーネルの活動をして、意見を表明したことがある大部分の女性は、前
向きな経験をもっています。

言葉の壁は英語が得意でない一部の人には問題になります。
メーリングリストの中できちんとアイディアを交換するには、相当うまく英語
を操れる必要があることもあります。そのため、あなたは自分のメール
を送る前に英語で意味が通じているかをチェックすることをお薦めします。

変更を分割する
---------------------

Linux カーネルコミュニティは、一度に大量のコードの塊を喜んで受容するこ
とはありません。変更は正確に説明される必要があり、議論され、小さい、個
別の部分に分割する必要があります。これはこれまで多くの会社がやり慣れて
きたことと全く正反対のことです。あなたのプロポーザルは、開発プロセスのと
ても早い段階から紹介されるべきです。そうすれば あなたは自分のやってい
ることにフィードバックを得られます。これは、コミュニティからみれば、あ
なたが彼らと一緒にやっているように感じられ、単にあなたの提案する機能の
ゴミ捨て場として使っているのではない、と感じられるでしょう。
しかし、一度に 50 もの email をメーリングリストに送りつけるようなことは
やってはいけません、あなたのパッチ群はいつもどんな時でもそれよりは小さ
くなければなりません。

パッチを分割する理由は以下です-

1) 小さいパッチはあなたのパッチが適用される見込みを大きくします、カー
   ネルの人達はパッチが正しいかどうかを確認する時間や労力をかけないか
   らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。
   しかし、500行のパッチは、正しいことをレビューするのに数時間かかるか
   もしれません(時間はパッチのサイズなどにより指数関数に比例してかかり
   ます)

   小さいパッチは何かあったときにデバッグもとても簡単になります。パッ
   チを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かお
   かしくなった後で)解剖するのに比べればとても簡単です。

2) 小さいパッチを送るだけでなく、送るまえに、書き直して、シンプルにす
   る(もしくは、単に順番を変えるだけでも)ことも、とても重要です。

以下はカーネル開発者の Al Viro のたとえ話です：

        "生徒の数学の宿題を採点する先生のことを考えてみてください、先
        生は生徒が解に到達するまでの試行錯誤を見たいとは思わないでしょ
        う。先生は簡潔な最高の解を見たいのです。良い生徒はこれを知って
        おり、そして最終解の前の中間作業を提出することは決してないので
        す"

        カーネル開発でもこれは同じです。メンテナ達とレビューア達は、
        問題を解決する解の背後になる思考プロセスを見たいとは思いません。
        彼らは単純であざやかな解決方法を見たいのです。

あざやかな解を説明するのと、コミュニティと共に仕事をし、未解決の仕事を
議論することのバランスをキープするのは難しいかもしれません。
ですから、開発プロセスの早期段階で改善のためのフィードバックをもらうよ
うにするのも良いですが、変更点を小さい部分に分割して全体ではまだ完成し
ていない仕事を(部分的に)取り込んでもらえるようにすることも良いことです。

また、でき上がっていないものや、"将来直す" ようなパッチを、本流に含め
てもらうように送っても、それは受け付けられないことを理解してください。

あなたの変更を正当化する
-------------------

あなたのパッチを分割するのと同時に、なぜその変更を追加しなければならな
いかを Linux コミュニティに知らせることはとても重要です。新機能は必要
性と有用性で正当化されなければなりません。

あなたの変更の説明
--------------------

あなたのパッチを送付する場合には、メールの中のテキストで何を言うかにつ
いて、特別に注意を払ってください。この情報はパッチの ChangeLog に使わ
れ、いつも皆がみられるように保管されます。これは次のような項目を含め、
パッチを完全に記述するべきです-

  - なぜ変更が必要か
  - パッチ全体の設計アプローチ
  - 実装の詳細
  - テスト結果

これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
ントの ChangeLog セクションを見てください-
  "The Perfect Patch"
      http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

これらのどれもが、時にはとても困難です。これらの慣例を完璧に実施するに
は数年かかるかもしれません。これは継続的な改善のプロセスであり、そのた
めには多数の忍耐と決意を必要とするものです。でも、諦めないで、これは可
能なことです。多数の人がすでにできていますし、彼らも皆最初はあなたと同
じところからスタートしたのですから。

Paolo Ciarrocchi に感謝、彼は彼の書いた "Development Process"
(http://linux.tar.bz/articles/2.6-development_process)セクショ
ンをこのテキストの原型にすることを許可してくれました。
Rundy Dunlap と Gerrit Huizenga はメーリングリストでやるべきこととやっ
てはいけないことのリストを提供してくれました。
以下の人々のレビュー、コメント、貢献に感謝。
Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
David A. Wheeler, Junio Hamano, Michael Kerrisk, と Alex Shepard
彼らの支援なしでは、このドキュメントはできなかったでしょう。

Maintainer: Greg Kroah-Hartman <[e-mail]>