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

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

[Akiyoshi Kurita]

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>
---
 .../ja_JP/process/submitting-patches.rst      | 166 ++++++++++++++++++
 1 file changed, 166 insertions(+)

diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst
index 91bd79a0e9dc..e1adab466507 100644
--- a/Documentation/translations/ja_JP/process/submitting-patches.rst
+++ b/Documentation/translations/ja_JP/process/submitting-patches.rst
@@ -180,3 +180,169 @@ 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")
+
+.. _split_changes:
+
+変更を分割する
+--------------
+
+各 **論理的な変更** は、個別のパッチに
+分けてください。
+
+たとえば、単一のドライバに対する変更の中に
+バグ修正と性能改善の両方が含まれているなら、
+それらは 2 つ以上のパッチに分けてください。
+また、変更に API の更新と、その新しい API を
+使う新しいドライバが含まれているなら、
+それらは 2 つのパッチに分けてください。
+
+一方、多数のファイルに対して 1 つの変更を行う
+場合は、それらを 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

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

[Akira Yokosawa]

On Sun, 19 Apr 2026 09:10:51 +0900, Akiyoshi Kurita wrote:
> 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>
> ---
>  .../ja_JP/process/submitting-patches.rst      | 166 ++++++++++++++++++
>  1 file changed, 166 insertions(+)

So, if I am counting lines in the English doc right, corresponding
3 sections are at lines 166--275.  275-166+1 = 110.
Why is your translation taking 50% more lines?

> 
> diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst
> index 91bd79a0e9dc..e1adab466507 100644
> --- a/Documentation/translations/ja_JP/process/submitting-patches.rst
> +++ b/Documentation/translations/ja_JP/process/submitting-patches.rst
> @@ -180,3 +180,169 @@ 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")
> +
> +.. _split_changes:

No, this will collide with the label in the English doc.
Please remember Sphinx treats these labels as global.

Also, there is no reference to this label in this patch.
Labels should be added only when they are referred to.

> +
> +変更を分割する
> +--------------
> +
> +各 **論理的な変更** は、個別のパッチに
> +分けてください。
> +
> +たとえば、単一のドライバに対する変更の中に
> +バグ修正と性能改善の両方が含まれているなら、
> +それらは 2 つ以上のパッチに分けてください。
> +また、変更に API の更新と、その新しい API を
> +使う新しいドライバが含まれているなら、
> +それらは 2 つのパッチに分けてください。

Ah, this time, you are breaking lines at 25 wide-char.
Why??? This doesn't help my reviewing at all.
Be consistent with yourself, please.

Thanks, Akira

[...]