ツリーは MAINTAINERS ファイル内の **T:** エントリを参照して見つけてください。
そこに掲載されていない場合は、メンテナに問い合わせてください。
-å¤\89æ\9b´å\86\85容ã\82\92説æ\98\8eする
+å¤\89æ\9b´å\86\85容ã\82\92è¨\98è¿°する
------------------
+
+問題を記述してください。あなたのパッチが 1 行のバグ修正であっても、
+5000 行の新機能であっても、それを行う動機となった根本的な問題が
+必ずあるはずです。修正すべき価値のある問題が存在し、レビューアが
+最初の段落以降を読む意味があることを納得させてください。
+
+ユーザーから見える影響を記述してください。クラッシュやロックアップは
+分かりやすいですが、すべてのバグがそこまで露骨とは限りません。
+たとえコードレビュー中に見つかった問題であっても、ユーザーに
+どのような影響があり得るかを記述してください。
+Linux の多くの環境は、上流から特定のパッチだけを取り込む二次的な
+安定版ツリーや、ベンダー／製品固有のツリーのカーネルで動いています。
+したがって、変更を下流へ適切に流す助けになる情報（発生条件、dmesg
+の抜粋、クラッシュ内容、性能劣化、レイテンシのスパイク、
+ロックアップ等）があれば記載してください。
+
+最適化とトレードオフを定量的に示してください。パフォーマンス、
+メモリ消費量、スタックフットプリント、バイナリサイズの改善を主張する
+場合は、それを裏付ける数値を記載してください。
+また、目に見えないコストについても記述してください。最適化は通常
+無料ではなく、CPU・メモリ・可読性の間でのトレードオフになります。
+ヒューリスティクスの場合は、異なるワークロード間でのトレードオフに
+なります。レビューアがコストとメリットを比較検討できるよう、
+最適化によって予想されるデメリットも記述してください。
+
+問題を明確にできたら、実際にどのような対策を講じているかを技術的に
+詳しく記述してください。レビューアがコードが意図したとおりに動作して
+いるかを確認できるよう、変更内容を平易な言葉で書き下すことが重要です。
+
+パッチ説明を Linux のソースコード管理システム ``git`` の
+「コミットログ」としてそのまま取り込める形で書けば、メンテナは
+助かります。詳細は原文の該当節を参照してください。
+
+.. TODO: Convert to file-local cross-reference when the destination is
+ translated.
+
+1 つのパッチでは 1 つの問題だけを解決してください。記述が長くなり
+始めたら、パッチを分割すべきサインです。詳細は原文の該当節を参照
+してください。
+
+.. TODO: Convert to file-local cross-reference when the destination is
+ translated.
projects / thirdparty / kernel / linux.git / commitdiff
