From: Akiyoshi Kurita Date: Sat, 2 May 2026 07:01:43 +0000 (+0900) Subject: docs/ja_JP: translate more of submitting-patches.rst X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=61e4155c81d1cc2b8a76344b65fd5fec41420cd6;p=thirdparty%2Flinux.git docs/ja_JP: translate more of submitting-patches.rst 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 Acked-by: Akira Yokosawa Signed-off-by: Jonathan Corbet Message-ID: <20260502070143.1015416-1-weibu@redadmin.org> --- diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst index 9d63220abd15b..928e38a8d34dc 100644 --- a/Documentation/translations/ja_JP/process/submitting-patches.rst +++ b/Documentation/translations/ja_JP/process/submitting-patches.rst @@ -83,19 +83,18 @@ Linux の多くの環境は、上流から特定のパッチだけを取り込 詳しく説明してください。コードが意図したとおりに動作していることを レビューアが確認できるよう、変更内容を平易な言葉で書き下すことが重要です。 -パッチの説明が Linux のソースコード管理システム ``git`` の「コミットログ」 -としてそのまま取り込める形で書かれていれば、メンテナは助かります。 -詳細は原文の該当節 ("The canonical patch format") を参照してください。 +パッチ説明を Linux のソースコード管理システム ``git`` の +「コミットログ」としてそのまま取り込める形で書けば、メンテナは +助かります。詳細は原文の該当節 ("The canonical patch format") を +参照してください。 .. TODO: Convert to file-local cross-reference when the destination is translated. 1 つのパッチでは 1 つの問題だけを解決してください。記述が長くなり -始めたら、それはパッチを分割すべきサインです。 -詳細は原文の該当節 ("Separate your changes") を参照してください。 +始めたら、パッチを分割すべきサインです。詳細は `変更を分割する`_ を +参照してください。 -.. TODO: Convert to file-local cross-reference when the destination is - translated. パッチまたはパッチシリーズを投稿／再投稿する際は、その完全な 説明と、それを正当化する理由を含めてください。単に「これはパッチ @@ -179,3 +178,117 @@ URL は禁止です。 $ 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 です。彼のメールアドレスは + です。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 してください。