私はLaunchpadとBazaarを初めて使用し、バグ修正を提出する最善の方法を見つけようとしています。Launchpad でホストされているかなり人気のあるオープンソース ソフトウェアを使用していますが、あまり安定していません。プロジェクトの独自のブランチを作成して安定させ、進行中の開発から他の変更を追加することなく、必要なバグ修正のみを適用しました。
バグを報告して自分で修正する方法を見つけたら、修正を安定版ブランチにプッシュします。修正をメイン プロジェクトに公開するにはどうすればよいですか? パッチ ファイルを作成してバグに添付するか、安定版ブランチのマージを提案することができます。
複数のバグを修正する場合、それぞれのバグに対して個別のマージ提案を行うことはできますか、それとも累積的ですか?
更新: OpenERP プロジェクトの公式ドキュメントに、マージ提案を作成するためのガイドラインが追加されたようです。詳細が異なるため、私のバージョンもここに残します。
数日間 Bazaar と Launchpad をいじり、いくつかのパッチとマージの提案を提出した後、見つけたものの要約を書きたいと思いました。Launchpad と Bazaar は、特にコミュニティ主導のプロジェクト向けにいくつかの強力なツールを提供していますが、新しいユーザーがまだ成功の穴に落ちる可能性は低いと思います。プロセスを遅くしてイライラさせる方法はいくつかあるので、このウォークスルーがいくつかの間違いを避けるのに役立つことを願っています.
これは、バグ修正に取り組み、Launchpad でホストされているプロジェクトのマージ提案をチームに提出するために私が学んだワークフローです。私は GNU/Linux ワークステーションで作業していますが、Bazaar コマンドは他のプラットフォームでも同等であると思います。この例では、OpenObject Addons という OpenObject プロジェクト グループのプロジェクトの 1 つに取り組んでいます。メンテナのユーザー名は openerp です。~/workspaceワークスペースをフォルダーに入れます。
ここにあるコマンドの詳細を知りたい場合はbzr help、コマンド名にプラスして使用してください。
プロジェクトに貢献したい機能ごとにブランチを作成するので、ブランチごとにプロジェクトの全履歴の個別のコピーを持ちたくありません。それを避けるために、共有リポジトリを作成し、その中に各ブランチを作成します。注意すべきことの 1 つは、後の手順の一部を機能させるために、リポジトリの形式が公式ブランチの形式と一致している必要があることです。
公式ブランチでリポジトリの形式を確認します。
bzr info http://bazaar.launchpad.net/~openerp/openobject-addons/5.0
ここで、マシン上のローカル ブランチを保持するワークスペース フォルダーを作成します。プロジェクトにちなんで名前を付けます。次に、公式ブランチで見つけた形式を使用して、その中に共有リポジトリを作成します。
cd ~
mkdir workspace
cd workspace
mkdir openobject-addons
cd openobject-addons
bzr init-repo --format=rich-root-pack .
次のステップは、公式ブランチからソース コードをチェックアウトすることです。通常はトランクと呼ばれますが、バグ修正に使用されている安定版リリース ブランチを使用することをお勧めします。この例では、5.0 リリース ブランチで作業します。
cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ feature-x
プロジェクト全体のすべてのコードとすべての履歴をハード ドライブにコピーするため、このステップはおそらく大規模なプロジェクトのプロセス全体で最も時間がかかります。作業する機能にちなんでブランチに名前を付けていることに注意してください。
この時点で、ローカル ワークステーションでコードのビルドと実行を試すことができます。コードを変更することはできますが、公式ブランチに直接コミットすることはおそらく許可されていないため、まだコミットする場所がありません。コードの変更を公開するには、パブリック ブランチを作成する必要があります。Launchpad を初めて使用する場合は、最初にアカウントを作成して公開キーを登録する必要があります。
アカウントを設定したら、自分のブランチを公式ブランチのコピーとして公開し、それで作業を開始できます。このlp-loginコマンドは、ランチパッド サイトで使用するアカウント名を bazaar に通知し、whoamiコミットする各リビジョンで使用する名前を bazaar に通知します。で使用するwhoami電子メール アドレスは、Launchpad アカウント用に構成した電子メール アドレスのいずれかと一致する必要があります。
cd ~/workspace/openobject-addons/feature-x
bzr lp-login donkirkby
bzr whoami "Don Kirkby <donkirkby@example.com>"
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/feature-x
新しいブランチに切り替えて、コミットがローカル履歴とパブリック ブランチに記録されるようにします。checkout と branch の違いについて学びたいと思うかもしれません。これをスタック ブランチにするということは、公式ブランチにない履歴のみが含まれているため、作成が非常に高速であることを意味します。このブログ投稿では、パブリック プロジェクトのブランチをデフォルトでスタックする必要があるように聞こえますが、それは私にとってはうまくいきませんでした。追加したい機能にちなんでブランチに名前を付けたことに注意してください。Bialixが提案したように、私は最終的に公式ブランチにマージすることを提案する機能ごとに個別のブランチを作成します。
ブランチが作成されたので、コードを変更してコミットできます。
cd ~/workspace/openobject-addons/feature-x
bzr commit -m "Fixed bug lp:12345 by fleaking the woverbinate() function."
ブランチ構造内のどこからでもコミットでき、デフォルトでブランチ全体がコミットされます。詳細については、実行bzr help commitしてください。bzr statusまた、役に立つかもしれませんbzr diff。
変更に満足し、機能ブランチにすべてをコミットしたら、Launchpad Web サイトに移動して、マージ提案を作成できます。ブランチの Web ページを起動するために実行できる便利なショートカットを次に示します。
cd ~/workspace/openobject-addons/feature-x
bzr lp-open
マージ提案を作成すると、Launchpad はその差分を生成します。その差分を確認する価値は十分にあります。ときどきターゲットとして間違ったブランチを選択してしまい、差分に予想以上の変更があったことに気が付きました。bzr sendマージ提案用のコマンドもありますが、私は使用していません。
プロセスを通じて提案を導くための電子メール インターフェイスがあります。または、Web サイトを使用することもできます。
ブランチをバグに添付して、他の人が自分のシステムでパッチのように使用できるようにすることも役立ちます。
あなたがいくつかの機能に取り組んでいて、メンテナーがあなたの提案をあまり迅速にレビューしない場合は、おそらく独自のメインライン ブランチを設定する価値があります。このブランチは、すべての機能をまとめて、サーバーで実行するコードを保持します。また、公式ブランチがあまり安定しておらず、本番環境用にブランチを安定させたい場合にも役立ちます。次に、いつ最新版にアップグレードするか、ユーザーに損害を与えているバグの特定のパッチをいつ適用するかを決定できます。
最初のステップは、公式ブランチにスタックされる別のブランチを作成することです。
cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ main
cd main
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/main
ここで、マージする必要がある変更のソースが 2 つあります。まず、機能またはバグ修正ブランチからマージします。
cd ~/workspace/openobject-addons/main
bzr merge lp:~donkirkby/openobject-addons/feature-x/
bzr commit -m "Merged feature x"
もちろん、フィーチャー ブランチのローカル コピーがまだある場合は、ローカル マージを行う方が高速です。
cd ~/workspace/openobject-addons/main
bzr merge ../feature-x
bzr commit -m "Merged feature x"
次に、公式ブランチから最新のものと最高のものをマージしたい場合があります。
cd ~/workspace/openobject-addons/main
bzr merge --remember lp:~openerp/openobject-addons/5.0/
bzr commit -m "Merged from 5.0 branch"
公式ブランチからのマージ時に使用した後--rememberは、そのまま公式ブランチからのマージに使用できますbzr merge。プロジェクトがタグを使用してリリース ポイントをマークしている場合、タグのリストを表示して、タグからマージできます。
cd ~/workspace/openobject-addons/main
bzr tags -d lp:~openerp/openobject-addons/5.0/
bzr merge -r tag:5.0.7rc2
そのようなポリシー (マージ提案またはパッチを使用) は、プロジェクト自体のコア開発者またはメンテナーによって定義されるべきです。しかし、一般的なルールとして、修正ごとに個別のブランチを使用することは、単純なパッチよりも望ましい方法です。
すべての修正を 1 つのブランチに保持することは、マージ提案で使用するには適していません。しかし、それ自体は、すべての修正をテストしたり、安定したブランチとして使用したりするのに役立ちます (例: ドッグフーディング)。したがって、個別の修正ごとに個別の (機能) ブランチを使用し、個別のマージ提案をファイルし、これらのブランチを安定したブランチにマージすることをお勧めします。このようにして、各修正に追加の変更を適用する自由を完全に得ることができ、それを安定したブランチに再度マージできます。
既存の安定版ブランチをいくつかの個別のブランチに分割する必要がある場合は、John Meinel のブログで説明されているレシピを使用できます: http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review- and-keep.html