Umi Blog
ウミブログ
本日は OSS プロジェクトとしての Drupal （ドルーパル）にコントリビュートバックする方法のひとつである「 パッチの投稿 」に関するドキュメントを日本語に翻訳してご紹介したいと思います。
元記事はこちら。
Drupal の場合はコアでもコントリビュートモジュールでも開発の大きな流れは共通です。 今回ご紹介する記事に書かれている方法を押させておきさえすれば、コアでもコントリビュートモジュールでも「パッチの送信」という形で貢献を行うことができるようになります。
パッチの作成/送信は Drupal プロジェクトに開発という形で貢献する上では欠かせないポイントになるかと思いますので、そのあたりに興味のある方はぜひご参考になさっていただければと思います。
ちなみに、 Drupal プロジェクトに貢献する方法に関してはこのところいくつかの記事を翻訳してご紹介をしています。 興味のある方はあわせてこちらもご覧になってみてください。
では以下が「 Submitting patches 」という記事の翻訳です。 いつものように日本語としてのわかりやすさを重視し直訳/意訳を織り交ぜています。 原文の厳密なニュアンスが知りたい方は原文の方も参照してみてください。 なお、翻訳元には最終更新日2014年11月7日のバージョンを使用しています。
このページでは Drupal のコアプロジェクトやコントリビュートプロジェクトにパッチを送る際のガイドラインをリストアップしています。 これらのガイドラインに従うと、あなたのパッチがレビューされコミットしてもらえるチャンスが上がります。 また、 Drupal コアとコントリビュートプロジェクトは qa.drupal.org ボットを使ってテストされますし、パッチスタイルの検証はテストプロセスの重要な要素となっています。 実際にパッチを作成する方法に関する情報は Git による Drupal パッチの作成セクションに載っています。
もしあなたがバグを発見しそれを修正したら、他の誰かが同じバグを見つけてバグレポートを投稿し、ひょっとしたらパッチまで投稿している可能性が常にあります。 対象となるバグに関するイシューがあるのを見つけたら、新しいキューを始めるのではなくそこにパッチを送信したりすでに出ているパッチをレビューしたりすることで時間を大幅に節約することができます。 この方法にはいくつかのメリットがあります: パッチは正しく機能することがレビューされ検証されたときにのみコミットされます（たいていはプロジェクトメンテナ以外の誰かが行います）。既存のイシューに投稿するとそのイシューにコメントをした人たちがアップデート通知を受け取ることになるため、他の人にパッチを見てもらえるチャンスがずっと高くなります。 既存のパッチをレビューすることはコミュニティ内のあなたの評価を高め、後ほど自分のパッチのレビューをより素早く受けられるようになります。 同じバグが複数のバージョンにありながらそのうちのひとつのバージョンにのみレポートが出されており最新のバージョンがひとまず修正されているといったこともあるため、バージョンを限定せずにイシューを検索するようにしましょう。
コアモジュールの場合でもコントリビュートモジュールの場合でも、パッチは必ず最新の開発版に対して送るようにしましょう。 Drupal 6 でバグを見つけたら、同じバグが Drupal 7 や Drupal 8 （最新版）で見つかる可能性があります。 実際に最新の開発版のコードを取得する方法については Git を使った Drupal パッチの作成のセクションで見つけることができます。
それが可能な場合には、バグはまず最新の開発版において修正されてから安定版のブランチへとバックポートされます。 こうすることでバージョン間のコードに一貫性が出ます。 古いブランチで修正されたバグフィックスは新しいリリースには含まれません。 たいてい開発版は活動が盛んなのでパッチのリファインとベストソリューションのための取り組みは開発版のブランチのキューの中の方が効率的に行われるでしょう。 このルールはコントリビュートモジュールにおいてよくあてはまりますが、異なるルールが採用されている場合もあるためまずはイシューキューをチェックするようにしましょう。
最新の開発版にバグが存在しない場合は、そのバグが開発版ではすでに修正されており、あなたがバグを発見したバージョンにパッチをバックポートする必要があるケースもあります。 その場合はまずは再度イシューキューを検索しましょう。 既存のイシューが見つからない場合はバグが見つかった最新版に対して投稿を行いましょう。 ふたつ以上のバージョンにバグを見つけた場合は各バージョンにイシューを入れるべきではありません。 代わりに最新の開発版にイシューを投稿し修正を加えた各バージョンへのパッチをそこに添付しましょう。
あなたのコードがコーディングスタンダード からかけ離れている場合はさらなるレビューを受けることなくリジェクトされます。 スタイルエラーの発見を促進するためには Coder モジュールでコードをチェックした方がよいかもしれません。 コメントやドキュメントがしっかりしているコードはよい印象を与えます。 コードがセキュリティガイドラインに沿っていることは必ず確認しておきましょう！ 明らかなことですが、セキュリティイシューを含むコードはリジェクトされるでしょう。
さぁ、最新の開発バージョンを手に入れてコーディングスタイルとセキュリティガイドラインを読んだら、変更を加えていきましょう。 投稿は必ず最新の開発版に対して行うようにしてください。
あなたのパッチに含まれる変更点の詳細を説明します。 できるかぎり具体的な記述を心がけましょう。 マーケティングよりも技術的な理由の説明の方が好まれるということを知っておいてください。 なぜ「このアプローチ」がよいのかという説明をはっきりと書きましょう。 明確な理由とともに変更点の妥当性を伝えてください。 パッチの対象バージョンを示すことは大切です。 他の人たちが（コードそのものをレビューすることではなく）あなたのパッチをテストすることを促進するため、テストサイトでパッチの影響を確認するために着目すべき問題点や実行すべき具体的なステップについての基本的な解説を提供することも必要でしょう。
パッチに名前をつけることは、一度にたくさんのパッチを処理する人たち（例えばコアコミッターの人たち）がパッチの管理をかんたんにできるようにするための重要なステップです。 [project_name]-[short-description]-[issue-number]-[comment-number]-[drupal-version].patch などの標準化された命名規則を採用することはとても有益です。
例えば、 Drupal 7 のフォーラムモジュールのコメントタイトルに関するパッチで、イシュー番号 12345 のコメント番号 15 に添付されたパッチは次のような名前にすべきです: forum-comment-titles-12345-15-D7.patch 。
テストボットによるテストを行うべきでないパッチ（例えば、イシューの現在の API バージョンでは動作しないパッチなど）については「 do-not-test 」を .patch の前につけてください。 例えば「 drupal.do_nothing_555555-do-not-test.patch 」。
注意 イシュー #284899: Drupal url problem with clean urls が修正されるまでパッチの名前にナンバーの記号（ # ）を含めないようにしてください。
レビュアーにはパッチ投稿のレビューとテストで負荷がかかっています。 彼らの仕事が楽になるよう次のことをチェックしてしてください:
パッチはイシュートラッカーを通して投稿されるべきです。 バグレポートかフィーチャーリクエストを作成し、ファイルアップロードフォームを使ってパッチを添付してください。 イシューのステータスを「 needs review 」または「 needs work 」にセットしましょう。 ステータスをこのふたつのうちにいずれかに設定するとイシューがパッチキューに追加されるので、ステータスの設定は重要です。
パッチを送信する前に、テスト対象モジュールを有効化してパッチをローカル環境でテストしましょう。 そうしておくと、そのパッチには失敗となるテストケースがないことを確かめ、パッチの自動テストの間に失敗が起こる可能性を減らすことができます。
・・・以上です。 いかがだったでしょうか？
今回はパッチという形で Drupal プロジェクトに貢献するときのルールと気をつけるべきポイントについて解説した記事を翻訳してご紹介しました。
技術的なポイントだけでなく、 Drupal ならではのローカルルールもありますので、興味のある方はぜひご参考にしていただければと思います。
今後も引き続きコントリビュート関連のドキュメントをご紹介していきます。
小さなご意見も、私たちにとっては大きなヒントです！
ぜひ率直なご感想をお寄せください
この
Masters of Drupal Engineering.
人に、
