man-pages パッチ、少なくとも変更の通知を送って、情報が
マニュアルページに反映されるようにしてください。ユーザー空間 API の
変更は、linux-api@vger.kernel.org にも Cc してください。
+
+MIME・リンク・圧縮・添付なし、プレーンテキストのみ
+----------------------------------------------------
+
+Linus や他のカーネル開発者は、あなたが投稿する変更を読み、
+コメントできる必要があります。カーネル開発者が標準的な
+メールツールを使ってあなたの変更を「引用」し、コードの特定の
+箇所についてコメントできることが重要です。
+
+このため、すべてのパッチはメール本文中に ``inline`` で投稿すべきです。
+これを行う最も簡単な方法は ``git send-email`` を使うことであり、
+強く推奨されます。``git send-email`` の対話型チュートリアルは
+https://git-send-email.io で利用できます。
+
+``git send-email`` を使わないことを選ぶ場合:
+
+.. warning::
+
+ パッチをコピー＆ペーストする場合は、エディタの word-wrap によって
+ パッチが壊れないよう注意してください。
+
+圧縮の有無にかかわらず、パッチを MIME 添付ファイルとして添付しては
+いけません。多くの一般的なメールアプリケーションは、MIME 添付
+ファイルを常にプレーンテキストとして送信するとは限らず、あなたの
+コードにコメントできなくなります。MIME 添付ファイルは Linus が
+処理するのにも少し余分な時間がかかるため、MIME 添付された変更が
+受け入れられる可能性を下げます。
+
+例外: メーラがパッチを壊してしまう場合は、誰かから MIME を使って
+再送するよう求められることがあります。
+
+パッチを変更せずに送信するようメールクライアントを設定するための
+ヒントについては、Documentation/process/email-clients.rst を参照してください。
+
+
+レビューコメントに返答する
+--------------------------
+
+あなたのパッチには、ほぼ確実に、パッチを改善する方法について
+レビューアからコメントが付きます。それは、あなたのメールへの返信という
+形で届きます。それらのコメントには必ず返答してください。レビューアを
+無視することは、こちらも無視されるためのよい方法です。コメントに
+答えるには、単にそのメールへ返信すれば構いません。コード変更に
+つながらないレビューコメントや質問であっても、次のレビューアが状況を
+よりよく理解できるように、ほぼ確実にコメントまたは changelog エントリに
+反映すべきです。
+
+どのような変更を行うのかをレビューアに必ず伝え、時間を割いてくれた
+ことに感謝してください。コードレビューは疲れる、時間のかかる作業であり、
+レビューアが不機嫌になることもあります。そのような場合であっても、
+丁寧に返答し、指摘された問題に対応してください。次の版を送るときは、
+cover letter または個々のパッチに ``patch changelog`` を追加し、前回の
+投稿との差分を説明してください。詳細は原文の該当節
+("The canonical patch format") を参照してください。
+
+.. TODO: Convert to file-local cross-reference when the destination is
+ translated.
+
+あなたのパッチにコメントした人には、パッチの Cc リストに追加して、
+新しい版を知らせてください。
+
+メールクライアントとメーリングリストでの作法についての推奨事項は、
+Documentation/process/email-clients.rst を参照してください。
projects / thirdparty / kernel / linux.git / commitdiff
