[PATCH v2] docs/ja_JP: translate more of submitting-patches.rst

[Akiyoshi Kurita <weibu@redadmin.org>]

Translate the "Separate your changes", "Style-check your changes",
and "Select the recipients for your patch" sections in
Documentation/translations/ja_JP/process/submitting-patches.rst.

Keep the wording close to the English text and wrap lines to match
the style used in the surrounding Japanese translation.

Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org>
---
v2:
 - drop conflicting label
 - rewrap lines more consistently

 .../ja_JP/process/submitting-patches.rst      | 122 ++++++++++++++++++
 1 file changed, 122 insertions(+)

diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst
index 91bd79a0e9dc..67f19a9a325d 100644
--- a/Documentation/translations/ja_JP/process/submitting-patches.rst
+++ b/Documentation/translations/ja_JP/process/submitting-patches.rst
@@ -180,3 +180,125 @@ lore.kernel.org のメッセージアーカイブサービスを使ってくだ
 
     $ git log -1 --pretty=fixes 54a4f0239f2e
     Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
+
+変更を分割する
+--------------
+
+各 **論理的な変更** は、個別のパッチに
+分けてください。
+
+たとえば、単一のドライバに対する変更にバグ修正と性能改善の
+両方が含まれるなら、それらは 2 つ以上のパッチに
+分けてください。変更に API の更新と、その新しい API を使う
+新しいドライバが含まれるなら、それらは 2 つのパッチに
+分けてください。
+
+一方、多数のファイルに対して単一の変更を行う場合は、それらを
+1 つのパッチにまとめてください。つまり、1 つの論理的な変更は
+1 つのパッチに含めるべきです。
+
+覚えておくべき点は、各パッチがレビューアに理解しやすく、
+検証できる変更であるべきだということです。各パッチは、
+それ自体の妥当性で正当化できなければなりません。
+
+変更を完成させるために、あるパッチが別のパッチに依存するなら、
+それでも構いません。単に、パッチの説明に
+**"this patch depends on patch X"** と記してください。
+
+変更を一連のパッチに分ける際は、シリーズ中の各パッチを
+適用した後でも、カーネルが正しくビルドされ、正常に動作することを
+特に注意して確認してください。問題の追跡に ``git bisect`` を
+使う開発者は、あなたのパッチシリーズを任意の地点で分割する
+ことがあります。途中でバグを持ち込めば、彼らに感謝されることは
+ないでしょう。
+
+パッチセットをこれ以上小さくできないなら、一度に投稿するのは
+15 個程度までにして、レビューと統合を待ってください。
+
+
+変更のスタイルを確認する
+------------------------
+
+パッチに基本的なスタイル違反がないか確認してください。詳細は
+Documentation/process/coding-style.rst を参照してください。
+これを怠ると、単にレビューアの時間を無駄にするだけでなく、
+パッチはおそらく読まれもせずに却下されます。
+
+大きな例外が 1 つあります。コードをあるファイルから別の
+ファイルへ移動する場合です。このときは、コードを移動する
+その同じパッチの中で、移動したコードを一切変更してはいけません。
+そうすることで、コードの移動という行為と、あなたの変更とを
+明確に区別できます。これは実際の差分のレビューを大いに助け、
+ツールがコード自体の履歴をより適切に追跡できるようにします。
+
+提出前に、パッチスタイルチェッカー
+(``scripts/checkpatch.pl``) でパッチを確認してください。
+ただし、スタイルチェッカーは指針として見るべきであり、
+人間の判断に取って代わるものではないことに注意してください。
+違反があっても、その方がコードの見栄えがよいなら、
+そのままにしておくのが最善でしょう。
+
+チェッカーは 3 つのレベルで報告します:
+
+ - ERROR: 間違っている可能性が非常に高いもの
+ - WARNING: 慎重なレビューを要するもの
+ - CHECK: 検討を要するもの
+
+パッチに残した違反については、すべて理由を説明できなければ
+なりません。
+
+
+パッチの宛先を選択する
+----------------------
+
+各パッチでは、そのコードを保守する適切なサブシステムメンテナと
+メーリングリストを、必ず Cc に入れてください。誰がその
+メンテナかは、MAINTAINERS ファイルとソースコードの改訂履歴を
+調べて確認してください。この段階では ``scripts/get_maintainer.pl``
+が非常に役立ちます（パッチへのパスを引数として
+``scripts/get_maintainer.pl`` に渡してください）。作業中の
+サブシステムのメンテナが見つからない場合は、Andrew Morton
+(akpm@linux-foundation.org) が最後の手段となるメンテナです。
+
+すべてのパッチでは、デフォルトで
+linux-kernel@vger.kernel.org を使うべきですが、このリストの
+流量が多いため、目を通さなくなった開発者も少なくありません。
+とはいえ、無関係なメーリングリストや無関係な人々に
+スパムを送らないでください。
+
+カーネル関連のメーリングリストの多くは kernel.org で
+運営されており、その一覧は https://subspace.kernel.org で
+確認できます。ただし、他所で運営されているカーネル関連の
+メーリングリストもあります。
+
+Linux カーネルに採用されるすべての変更の最終的な裁定者は
+Linus Torvalds です。彼のメールアドレスは
+<torvalds@linux-foundation.org> です。Linus は大量の
+メールを受け取っており、現時点では彼に直接届くパッチは
+ごくわずかなので、通常は彼にメールを送ることを極力
+避けてください。
+
+悪用可能なセキュリティバグを修正するパッチがあるなら、
+そのパッチを security@kernel.org に送ってください。
+深刻なバグについては、ディストリビュータがユーザーに
+パッチを配布できるよう、短期間の embargo が検討される
+場合があります。そのような場合、そのパッチを公開
+メーリングリストに送るべきではありません。
+Documentation/process/security-bugs.rst も参照してください。
+
+リリース済みカーネルの深刻なバグを修正するパッチは、
+次のような行をパッチの sign-off 欄に入れることで、
+stable メンテナへ向けてください::
+
+  Cc: stable@vger.kernel.org
+
+これはメールの受信者ではないことに注意してください。
+また、この文書に加えて
+Documentation/process/stable-kernel-rules.rst も読んでください。
+
+変更がユーザーランドとカーネルのインターフェースに
+影響する場合は、MAINTAINERS ファイルに記載されている
+MAN-PAGES メンテナに man-pages パッチ、少なくとも
+変更の通知を送って、情報がマニュアルページに
+反映されるようにしてください。ユーザー空間 API の変更は、
+linux-api@vger.kernel.org にも Cc してください。
-- 
2.47.3