mirror of
https://github.com/torvalds/linux.git
synced 2026-07-27 17:47:41 +02:00
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 <weibu@redadmin.org> Acked-by: Akira Yokosawa <akiyks@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260502070143.1015416-1-weibu@redadmin.org>
This commit is contained in:
parent
cb7083f9db
commit
61e4155c81
|
|
@ -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 です。彼のメールアドレスは
|
||||
<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 してください。
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user