From: Akiyoshi Kurita <weibu@redadmin.org>
To: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, corbet@lwn.net, akiyks@gmail.com,
weibu@redadmin.org
Subject: [PATCH] docs/ja_JP: translate more of submitting-patches.rst
Date: Sun, 19 Apr 2026 09:10:51 +0900 [thread overview]
Message-ID: <20260419001051.389599-1-weibu@redadmin.org> (raw)
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
reply other threads:[~2026-04-19 0:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260419001051.389599-1-weibu@redadmin.org \
--to=weibu@redadmin.org \
--cc=akiyks@gmail.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox