submittingpatches

linux 内核源代码

<http://vger.kernel.org/vger-lists.html>

もし、変更がユーザランドのカーネルインタフェースに影響を与え
るのであれば、MAN-PAGES のメンテナ( MAINTAINERS ファイルに一覧
があります)に man ページのパッチを送ってください。少なくとも
情報がマニュアルページの中に入ってくるように、変更が起きたという
通知を送ってください。

たとえ、メンテナが #4 で反応がなかったとしても、メンテナのコードに変更を
加えたときには、いつもメンテナに CC するのを忘れないようにしてください。

小さなパッチであれば、Adrian Bunk が管理している Trivial Patch Monkey
(ちょっとしたパッチを集めている)<[e-mail]>に CC してもいい
です。ちょっとしたパッチとは以下のルールのどれか1つを満たしていなけ
ればなりません。
 ・ドキュメントのスペルミスの修正
 ・grep(1) コマンドによる検索を困難にしているスペルの修正
 ・コンパイル時の警告の修正(無駄な警告が散乱することは好ましくないた
   めです)
 ・コンパイル問題の修正(それらの修正が本当に正しい場合に限る)
 ・実行時の問題の修正(それらの修正が本当に問題を修正している場合に限る)
 ・廃止予定の関数やマクロを使用しているコードの除去(例 check_region )
 ・問い合わせ先やドキュメントの修正
 ・移植性のないコードから移植性のあるコードへの置き換え(小さい範囲で
   あればアーキテクチャ特有のことでも他の人がコピーできます)
 ・作者やメンテナによる修正(すなわち patch monkey の再転送モード)
URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>

7) MIME やリンクや圧縮ファイルや添付ファイルではなくプレインテキストのみ

Linus や他のカーネル開発者はあなたが投稿した変更を読んで、コメントでき
る必要があります。カーネル開発者にとって、あなたが書いたコードの特定の
部分にコメントをするために、標準的な電子メールクライアントで変更が引用
できることは重要です。

上記の理由で、すべてのパッチは文中に含める形式の電子メールで投稿さ
れるべきです。警告：あなたがパッチをコピー&ペーストする際には、パッ
チを改悪するエディターの折り返し機能に注意してください。

パッチを圧縮の有無に関わらず MIME 形式で添付しないでください。多くのポ
ピュラーな電子メールクライアントは MIME 形式の添付ファイルをプレーンテ
キストとして送信するとは限らないでしょう。そうなると、電子メールクラ
イアントがコードに対するコメントを付けることをできなくします。また、
MIME 形式の添付ファイルは Linus に手間を取らせることになり、その変更を
受け入れてもらう可能性が低くなってしまいます。

例外：お使いの電子メールクライアントがパッチをめちゃくちゃにするので
あれば、誰かが MIME 形式のパッチを再送するよう求めるかもしれません。

警告： Mozilla のような特定の電子メールクライアントは電子メールの
ヘッダに以下のものを付加して送ります。
---- message header ----
Content-Type: text/plain; charset=us-ascii; format=flowed
---- message header ----
問題は、「 format=flowed 」が付いた電子メールを特定の受信側の電子メール
クライアントがタブをスペースに置き換えるというような変更をすることです。
したがって送られてきたパッチは壊れているように見えるでしょう。

これを修正するには、mozilla の defaults/pref/mailnews.js ファイルを
以下のように修正します。
pref("mailnews.send_plaintext_flowed", false); // RFC 2646=======
pref("mailnews.display.disable_format_flowed_support", true);

8) 電子メールのサイズ

パッチを Linus へ送るときは常に #7 の手順に従ってください。

大きなパッチはメーリングリストやメンテナにとって不親切です。パッチが
未圧縮で 40KB を超えるようであるなら、インターネット上のアクセス可能な
サーバに保存し、保存場所を示す URL を伝えるほうが適切です。

9) カーネルバージョンの明記

パッチが対象とするカーネルのバージョンをパッチの概要か電子メールの
サブジェクトに付けることが重要です。

パッチが最新バージョンのカーネルに正しく適用できなければ、Linus は
そのパッチを採用しないでしょう。

10) がっかりせず再投稿

パッチを投稿した後は、辛抱強く待っていてください。Linus があなたのパッ
チを気に入って採用すれば、Linus がリリースする次のバージョンのカーネル
の中で姿を見せるでしょう。

しかし、パッチが次のバージョンのカーネルに入っていないなら、いくつもの
理由があるのでしょう。その原因を絞り込み、間違っているものを正し、更新
したパッチを投稿するのはあなたの仕事です。

Linus があなたのパッチに対して何のコメントもなく不採用にすることは極め
て普通のことです。それは自然な姿です。もし、Linus があなたのパッチを受
け取っていないのであれば、以下の理由が考えられます。
* パッチが最新バージョンの Linux カーネルにきちんと適用できなかった
* パッチが LKML で十分に議論されていなかった
* スタイルの問題(セクション2を参照)
* 電子メールフォーマットの問題(このセクションを参照)
* パッチに対する技術的な問題
* Linus はたくさんの電子メールを受け取っているので、どさくさに紛れて見
  失った
* 不愉快にさせている

判断できない場合は、LKML にコメントを頼んでください。

11) サブジェクトに「 PATCH 」

Linus や LKML への大量の電子メールのために、サブジェクトのプレフィックスに
「 [PATCH] 」を付けることが慣習となっています。これによって Linus や他の
カーネル開発者がパッチであるのか、又は、他の議論に関する電子メールであるの
かをより簡単に識別できます。

12) パッチへの署名

誰が何をしたのかを追いかけやすくするために (特に、パッチが何人かの
メンテナを経て最終的に Linux カーネルに取り込まれる場合のために)、電子
メールでやり取りされるパッチに対して「 sign-off 」という手続きを導入し
ました。

「 sign-off 」とは、パッチがあなたの書いたものであるか、あるいは、
あなたがそのパッチをオープンソースとして提供する権利を保持している、
という証明をパッチの説明の末尾に一行記載するというものです。
ルールはとても単純です。以下の項目を確認して下さい。

        原作者の証明書( DCO ) 1.1

        このプロジェクトに寄与するものとして、以下のことを証明する。

        (a) 本寄与は私が全体又は一部作成したものであり、私がそのファイ
            ル中に明示されたオープンソースライセンスの下で公開する権利
            を持っている。もしくは、

        (b) 本寄与は、私が知る限り、適切なオープンソースライセンスでカバ
            ーされている既存の作品を元にしている。同時に、私はそのライセ
            ンスの下で、私が全体又は一部作成した修正物を、ファイル中で示
            される同一のオープンソースライセンスで(異なるライセンスの下で
            投稿することが許可されている場合を除いて)投稿する権利を持って
            いる。もしくは、

        (c) 本寄与は(a)、(b)、(c)を証明する第3者から私へ直接提供された
            ものであり、私はそれに変更を加えていない。

	(d) 私はこのプロジェクトと本寄与が公のものであることに理解及び同意す
            る。同時に、関与した記録(投稿の際の全ての個人情報と sign-off を
            含む)が無期限に保全されることと、当該プロジェクト又は関連する
            オープンソースライセンスに沿った形で再配布されることに理解及び
            同意する。

もしこれに同意できるなら、以下のような1行を追加してください。

	Signed-off-by: Random J Developer <[e-mail]>

実名を使ってください。(残念ですが、偽名や匿名による寄与はできません。)

人によっては sign-off の近くに追加のタグを付加しています。それらは今のところ
無視されますが、あなたはそのタグを社内の手続きに利用したり、sign-off に特別
な情報を示したりすることができます。

13) いつ Acked-by: を使うのか

「 Signed-off-by: 」タグはその署名者がパッチの開発に関わっていたことやパッチ
の伝播パスにいたことを示しています。

ある人が直接パッチの準備や作成に関わっていないけれど、その人のパッチに対す
る承認を記録し、示したいとします。その場合、その人を示すのに Acked-by: が使
えます。Acked-by: はパッチのチェンジログにも追加されます。

パッチの影響を受けるコードのメンテナがパッチに関わっていなかったり、パッチ
の伝播パスにいなかった時にも、メンテナは Acked-by: をしばしば利用します。

Acked-by: は Signed-off-by: のように公式なタグではありません。それはメンテナが
少なくともパッチをレビューし、同意を示しているという記録です。そのような
ことからパッチの統合者がメンテナの「うん、良いと思うよ」という発言を
Acked-by: へ置き換えることがあります。

Acked-by: が必ずしもパッチ全体の承認を示しているわけではありません。例えば、
あるパッチが複数のサブシステムへ影響を与えており、その中の1つのサブシステム
のメンテナからの Acked-by: を持っているとします。その場合、Acked-by: は通常
そのメンテナのコードに影響を与える一部分だけに対する承認を示しています。
この点は、ご自分で判断してください。(その Acked-by: が)疑わしい場合は、
メーリングリストアーカイブの中の大元の議論を参照すべきです。

14) 標準的なパッチのフォーマット

標準的なパッチのサブジェクトは以下のとおりです。

    Subject: [PATCH 001/123] subsystem: summary phrase