OpenStack バグ修正 ステップ・バイ・ステップ
ステップ１：開発環境のセットアップ
1.1) 最も簡単な方法は、DevStack を使用して完全に機能する開発環境を構築する事です。DevStack を使う為に、Ubuntu 11.10 を実行しているマシンが必要です。既に OpenStack を実行中のマシンがある場合、1.4 までスキップして下さい。さもなければ、このまま次に進んで下さい。
1.2) この時点で、Ubuntu 11.10 を実行中のローカルの仮想マシンが必要です。１つの一般的な方法は、VirtualBox が実行可能であれば Vagrant を使用する事です。これ以降の手順は http://github.com/bcwaldon/vagrant_devstack を参照して下さい。
1.3) ローカルで VirtualBox やその他の仮想マシンを実行できない場合、クラウドに目を向ける必要があります。Amazon EC2 や Rackspace Cloud 上のアカウントをセットアップして、作業用の VM を実行して下さい。
1.4) http://devstack.org のガイドに従い、あなたの環境を準備して実行して下さい。
注意：もしあなたが DevStack を使用したくなくても、ソースコードをローカルマシンにチェックアウトしてそこで開発する事が出来ます。
ステップ２：CLA への署名と、LaunchPad へのサインイン
2.1) http://launchpad.net にアクセスし、上右端にある「Log in / Register」をクリックして、サインイン（アカウント作成）して下さい。一度あなたのアカウントを作成したら、あと幾つかやるべき事があります。
2.2) OpenStack CLA に署名します。http://wiki.openstack.org/CLA にて電子署名する事が出来ます。
2.3) Contributors ウィキページにあなた自身を追加します。http://wiki.openstack.org/Contributors のトップにある手順を参照して下さい。
2.4) LaunchPad の openstack-cla グループに参加します。この為には、https://launchpad.net/~openstack-cla にアクセスし、ページの右側にある「Join the team」をクリックします。あなたの参加リクエストは、それを承認する事ができる OpenStack の中心開発者達にフォワードされます。覚えておいて下さい。あなたの参加が承認されるためには、あなたは最初の２つのステップを完了しておかなければなりません。一度あなたのチームへの参加リクエストが送信されたら、開発を始めても構いません。ただ、コードを送信(submit)する前に、あなたの参加リクエストが承認されている必要がある事だけ覚えておいて下さい。
- 注意：この時点で、Freenode 上の #openstack-dev IRC チャンネルに参加するのは良い考えです。ここには常に開発者達がいて、コードレビューの手助けやその他のあなたが抱いている一般的な質問に答えてくれます。もし、ステップ３によるあなたの openstack-cla チームへの参加リクエスト（の未承認）があなたのコード送信を妨げているのに気づいたら、このチャットルームの誰かに気軽に声をかけて下さい。
ステップ３：バグの担当
3.1) OpenStack プロジェクトはそれらのバグレポートを全て LaunchPad 上で管理しています。以下のリンクのいずれかを辿って、各々のプロジェクトのオープン（未解決）で担当者のいないバグの一覧を参照して下さい。
Nova: http://bit.ly/xZokY4
Glance: http://bit.ly/wGmxOo
Swift: http://bit.ly/zgpu7w
Keystone: http://bit.ly/zHSZb5
Horizon: http://is.gd/9EyvUl
注意：あなたがまだ OpenStack の初心者であれば、バグフィルタの「low-hanging-fruit」を選択するのが良いでしょう。右のリンクをクリックし、このリストを参照して下さい。
- 3.2) 一旦あなたがリストを検索して作業したい何かを見つけたら、そのバグレポートを開き、「Assigned to」（担当者）列にある黄色いエディットボタンをクリックして、ポップアップボックス中の「Assign me」（自分を担当者にする）をクリックして下さい。また、バグのステータスも「In Progress」（作業中）にセットした方が良いでしょう。
ステップ４：バグの修正
これで、あなたは作業するものをピックアップしたので、あなたの開発環境に向かい、とことんやって下さい（go crazy!）。我々は、あなたが最初にバグレポートで開設された挙動を再現する為の失敗テスト（failing test）を作成する事を強くお勧めします。中心開発者は最終的に、あなたがコードレビューステップに進んだ時点で、バグ修正を検証するテストを要求します。テストを実行する為に、「run_tests.shシェルスクリプト」を探して下さい。これは、あなたが今いるプロジェクト用の全テストを実行し、（プログラミング）スタイルエラーのチェックを行います。
- 注意：あなたの特定のプロジェクトにおける初めての作業の場合、あなたは自分自身を AUTHORS ファイルに追加する必要があります。あなたの（ソースコード）リポジトリの最上位ディレクトリ中で AUTHORS ファイルを探して下さい。
もし、レポートの詳細にあるバグの再現が出来ない場合、気軽に周囲の人に問い合わせて下さい。いくつかのバグは正しく設定されなかった環境の為に発生したり、非常に稀な状況でのみ現れたりします。これらは各プロジェクトの中心メンバーの一覧です。
Keystone: https://launchpad.net/~keystone-core/+members#active
Horizon: https://launchpad.net/~horizon-core/+members#active
ステップ５：修正の提案
- 5.1) あなたが自身のパッチを提案する前に、済ませておくべき事が若干あります。まず、「git-review」をインストールする必要があります。このツールは、我々のコードレビューツールで作業する為に、あなたのリポジトリと個々のパッチの幾つかの初期設定を手助けする「review」コマンドを git に追加します。git-review を入手する最も簡単な方法は、pip を使う事です:
pip install git-review
5.2) 次に、あなたの修正が単一のコミットに含まれており、そのコミットメッセージにバグへのリンクが含まれている事を確認する必要があります。この為には、我々は「git rebase -i origin/master」の実行を推奨します。このコマンドはあなたのコミット群を１まとめにする為に対話的エディタを開きます。この作業はまた、レビューに送られる予定のコミットメッセージを編集する事ができます。コミットメッセージに「Fixes bug XXXXXX」等の文字列が入っている場合、あなたの修正は自動的に LaunchPad 上のバグにリンクされます。もしこのステップで問題があった場合、http://wiki.openstack.org/GerritWorkflow/ja を参照するか、単に IRC で誰か捕まえて下さい。
- 5.3) 一旦あなたが git-review をインストールし、パッチをクリーンアップしたら、気軽に「git review」を実行して下さい。あなたのレビューへのリンクが画面に表示されるでしょう。この時点であなたは別のバグフィックスに移れます！もしあなたがアクセスすべき何らかのフィードバックをついに受け取ったら、次のステップに進んで下さい。
- 5.4) 一旦あなたがコード関連の問題を修正し、あなたのレビューを再送信する準備が整ったら、あなたは再度あなたのコミットを１つにまとめる必要があります。コミットメッセージ中の「Change-Id: ...」行を削除していない事を確認して下さい。この行はあなたの一連のパッチが１つのレビューに紐付ける為に Gerrit が使用する情報の一部です。後は、同じ「git review」コマンドを実行し、更新したコードを送信して下さい。