パッチの送信—Djangoドキュメント
パッチの送信
Djangoのコードへのパッチにはいつも感謝しています。 実際、パッチが関連付けられているバグレポートは、パッチがない場合よりもはるかに早く修正されます。
タイプミスの修正と簡単なドキュメントの変更
ドキュメント内の単語を変更するなど、非常に些細な問題を修正する場合、パッチを提供するための推奨される方法は、TracチケットなしでGitHubプルリクエストを使用することです。
プルリクエストの使用方法の詳細については、 GitとGitHubの操作を参照してください。
「主張」チケット
世界中に何百人もの貢献者がいるオープンソースプロジェクトでは、作業が重複しないようにコミュニケーションを効率的に管理し、貢献者が可能な限り効果的になることが重要です。
したがって、私たちのポリシーは、特定のバグまたは機能が処理されていることを他の開発者に知らせるために、寄稿者がチケットを「要求」することです。
作成したい貢献を特定し、それを修正できる場合（コーディング能力、Django内部の知識、および時間の可用性によって測定される）、次の手順に従ってそれを要求します。
- GitHubアカウントを使用してログインまたはチケットシステムにアカウントを作成します。 アカウントをお持ちでパスワードをお忘れの場合は、パスワードリセットページでリセットできます。
- この問題のチケットがまだ存在しない場合は、チケットトラッカーでチケットを作成してください。
- この問題のチケットがすでに存在する場合は、他の誰もそれを主張していないことを確認してください。 これを行うには、チケットの「所有者」セクションを確認してください。 「誰も」に割り当てられていない場合は、申し立てを行うことができます。 そうしないと、他の誰かがこのチケットに取り組んでいる可能性があります。 取り組むべき別のバグ/機能を見つけるか、チケットに取り組んでいる開発者に連絡して支援を提供してください。 チケットが何もアクティビティなしで数週間または数か月割り当てられている場合は、自分自身に再割り当てしても安全です。
- アカウントにまだログインしていない場合は、チケットページの左上にある[GitHubログイン]または[DjangoProjectログイン]をクリックしてログインします。
- ページ下部の[アクション]の下にある[自分に割り当てる]ラジオボタンをクリックしてチケットを請求し、[変更を送信]をクリックします。
ノート
Django Software Foundationは、Djangoに些細なパッチ以上の貢献をする人は誰でも、 Contributor License Agreement に署名して提出することを要求します。これにより、Django Software Foundationはすべての貢献に対して明確なライセンスを持ち、すべてのユーザーに明確なライセンスを与えることができます。 。
チケット請求者の責任
チケットを請求したら、合理的にタイムリーにそのチケットに取り組む責任があります。 作業する時間がない場合は、申し立てを行わないか、そもそも申し立てを行わないでください。
特定の請求されたチケットに1〜2週間進行の兆候がない場合、別の開発者がチケットの請求を放棄して、独占されなくなり、他の誰かが請求できるようにするように依頼する場合があります。
チケットを申請し、コーディングに長い時間（数日または数週間）かかる場合は、チケットにコメントを投稿して、全員に最新情報を提供してください。 定期的な更新を提供せず、進捗レポートのリクエストに応答しない場合、チケットに対する請求が取り消される可能性があります。
いつものように、コミュニケーションは少ないよりも多いほうがいいです！
どのチケットを請求する必要がありますか？
チケットを請求する手順を踏むのは、場合によってはやり過ぎです。
ドキュメントのタイプミスや修正に数分しかかからない小さなバグなどの小さな変更の場合は、チケットを要求するというフープを飛び越える必要はありません。 パッチを直接送信すれば完了です。
誰かがそれを主張したかどうかに関係なく、パッチの準備ができている場合は、チケットにパッチを送信することは常に許容されます。
パッチスタイル
貢献する場合は、少なくとも次の要件を満たしていることを確認してください。
- 問題の修正や機能の追加に必要なコードはパッチの重要な部分ですが、それだけではありません。 優れたパッチには、修正された動作を検証し、問題の再発を防ぐために、回帰テストも含める必要があります。 また、一部のチケットが作成したコードに関連している場合は、テストのコメントにチケット番号を記載して、パッチがコミットされてチケットが閉じられた後、関連するディスカッションを簡単にさかのぼることができるようにします。
- パッチに関連付けられたコードが新しい機能を追加したり、既存の機能の動作を変更したりする場合、パッチにはドキュメントも含まれている必要があります。
作業をレビューする準備ができたら、 GitHubプルリクエストを送信します。 まず、パッチレビューチェックリストを使用して、自分でパッチをレビューしてください。
何らかの理由でプルリクエストを送信できない場合は、Tracでパッチを使用することもできます。 このスタイルを使用する場合は、次のガイドラインに従ってください。
git diffコマンドで返された形式でパッチを送信します。- 「ファイル添付」ボタンを使用して、チケットトラッカーでチケットにパッチを添付します。 単一行のパッチでない限り、チケットの説明やコメントにパッチを入れないでください。
- パッチファイルに
.diff拡張子の名前を付けます。 これにより、チケットトラッカーは正しい構文の強調表示を適用できるようになります。これは非常に役立ちます。
作品の提出方法に関係なく、次の手順に従ってください。
- コードがパッチレビューチェックリストの要件を満たしていることを確認してください。
- チケットの「パッチあり」ボックスをチェックし、「ドキュメントが必要」、「テストが必要」、「パッチの改善が必要」ボックスがチェックされていないことを確認します。 これにより、チケットは開発ダッシュボードの「レビューが必要なパッチ」キューに表示されます。
重要なパッチ
「重要な」パッチは、小さなバグ修正以上のものです。 これは、Djangoの機能を導入し、ある種の設計上の決定を行うパッチです。
重要なパッチを提供する場合は、 django-developers で代替案が議論されているという証拠を含めてください。
パッチを重要と見なすべきかどうかわからない場合は、チケットで意見を求めてください。
機能の非推奨
Djangoのコードが非推奨になる理由はいくつかあります。
- 機能が後方互換性のない方法で改善または変更された場合、古い機能または動作は非推奨になります。
- Djangoには、Djangoが現在サポートしているバージョンのPythonに含まれていないPythonライブラリのバックポートが含まれている場合があります。 Djangoがライブラリを含まない古いバージョンのPythonをサポートする必要がなくなった場合、ライブラリはDjangoで非推奨になります。
非推奨ポリシーで説明されているように、機能を非推奨にするDjangoの最初のリリース（A.B）は、RemovedInDjangoXXWarning（XXは機能が含まれるDjangoバージョン）を起動する必要があります。非推奨の機能が呼び出されたとき）。 テストカバレッジが良好であると仮定すると、警告を有効にしてテストスイートを実行すると、これらの警告はエラーに変換されます：python -Wa runtests.py。 したがって、RemovedInDjangoXXWarningを追加するときは、テストの実行時に生成される警告を削除または消音する必要があります。
最初のステップは、Django自体による非推奨の動作の使用を削除することです。 次に、テストレベルまたはクラスレベルでignore_warningsデコレータを使用して、非推奨の動作を実際にテストするテストで警告を消音できます。
特定のテストでは：
from django.test import ignore_warnings from django.utils.deprecation import RemovedInDjangoXXWarning @ignore_warnings(category=RemovedInDjangoXXWarning) def test_foo(self): ...テストケース全体の場合：
from django.test import ignore_warnings from django.utils.deprecation import RemovedInDjangoXXWarning @ignore_warnings(category=RemovedInDjangoXXWarning) class MyDeprecatedTests(unittest.TestCase): ...
非推奨の警告のテストを追加することもできます。
from django.utils.deprecation import RemovedInDjangoXXWarning
def test_foo_deprecation_warning(self):
msg = 'Expected deprecation message'
with self.assertWarnsMessage(RemovedInDjangoXXWarning, msg):
# invoke deprecated behavior最後に、Djangoのドキュメントにいくつかの更新があります。
- 既存の機能がドキュメント化されている場合は、
.. deprecated:: A.Bアノテーションを使用して、ドキュメントで非推奨としてマークします。 該当する場合は、アップグレードパスに関する簡単な説明とメモを含めます。 - 「ABで非推奨になった機能」の見出しの下にある現在のリリースノート（
docs/releases/A.B.txt）に、非推奨の動作の説明と、該当する場合はアップグレードパスを追加します。 - 削除されるコードを説明する適切なバージョンの下の非推奨タイムライン（
docs/internals/deprecation.txt）にエントリを追加します。
これらの手順を完了すると、非推奨になります。 各機能リリースでは、新しいバージョンに一致するすべてのRemovedInDjangoXXWarningが削除されます。
パッチレビューチェックリスト
このチェックリストを使用して、プルリクエストを確認します。 自分のものではないプルリクエストを確認していて、以下のすべての基準に合格している場合は、対応するTracチケットの「トリアージステージ」を「チェックインの準備ができました」に設定してください。 プルリクエストの改善についてコメントを残した場合は、レビューの結果に基づいて、Tracチケットの適切なフラグにチェックマークを付けてください：「パッチには改善が必要」、「ドキュメントが必要」、「テストが必要」。 時間と関心が許す限り、コミッターは「チェックインの準備ができました」チケットの最終レビューを行い、さらに作業を行う必要がある場合は、パッチをコミットするか、「承認済み」に戻します。 コミッターになりたい場合は、パッチの徹底的なレビューを行うことは、信頼を得るための優れた方法です。
レビューするパッチをお探しですか？ Django開発ダッシュボードの「レビューが必要なパッチ」セクションを確認してください。 パッチのレビューをお探しですか？ チケットがそのキューに表示されるように、チケットのTracフラグが設定されていることを確認します。
ドキュメンテーション
- ドキュメントはエラーなしでビルドされますか（
make html、またはWindowsではmake.bat html、docsディレクトリから）？ - ドキュメントは、ライティングドキュメントのライティングスタイルガイドラインに準拠していますか？
- スペルミスはありますか？
バグ
- 適切な回帰テストはありますか（修正が適用される前にテストは失敗するはずです）？
- がDjangoの安定バージョンへのバックポートの対象となるバグの場合、
docs/releases/A.B.C.txtにリリースノートはありますか？ メインブランチにのみ適用されるバグ修正には、リリースノートは必要ありません。
新機能
- すべての新しいコードを「実行」するためのテストはありますか？
docs/releases/A.B.txtにリリースノートはありますか？- この機能のドキュメントはありますか？適切にに
.. versionadded:: A.Bまたは.. versionchanged:: A.Bの注釈が付けられていますか？
すべてのコード変更
- コーディングスタイルはガイドラインに準拠していますか？
flake8エラーはありますか？ pre-commit フックをインストールして、これらのエラーを自動的にキャッチできます。 - 変更に何らかの形で後方互換性がない場合、リリースノート（
docs/releases/A.B.txt）に注記がありますか？ - Djangoのテストスイートは合格ですか？
すべてのチケット
- プルリクエストは、コミットメッセージ形式に従ったメッセージを含む単一の押しつぶされたコミットですか？
- あなたはパッチの作者であり、新しい寄稿者ですか？
AUTHORSファイルに自分を追加し、寄稿者ライセンス契約を提出してください。
