Patch Queue Managerを使ってみる(その1)

ArX

tlaやbzrなどと同じようにArXも「本家プロジェクトのマネージャの負担が大きくなる」問題がある。どういうことかというと、誰でも本家にマージリクエストを出すことができて(出すのは自由だ)、マネージャが各リクエストを吟味して組み込む作業が大変になるということ。集中化SCMはリポジトリが一つしかないのでマージリクエストを処理するのは比較的単純だが、分散SCMの場合、おのおのが自立的に進化していくため、本家との乖離が大きくなった状態になりやすい。もちろん、それを解決するべきなのは本質的にはcontributorだ。

Patch Queue Mangerを使うと、マージリクエストの処理を自動化することができる。AIではないのでコンフリクトは即リジェクト。hook scriptに仕込んだunit testに引っかかってもリジェクト。一方、害はないが無駄なコードでもさくっとmerge success。

各contributorは本家からbranchして作業し、自信の持てる状況で、一回本家からmergeし(これ重要)、本家の最新状況を自分のbranchに組み込む。その後、本家へマージリクエストを投げる。しばらくすると本家が自分のパッチを組み込んでくれるという訳。
運が悪いとリジェクトされるが、そのときはもう一度本家から差分をマージしてコンフリクトを解決してリトライする。

このマージリクエストはなんとemailで行う。spamでリポジトリがめちゃくちゃにされてしまうと困るので、gpgでサインしたもののうち、信頼したものだけ受け付けるようになっている。また分散SCMはURI(と認証があるならその条件)さえわかればどこのリポジトリでも操作できちゃうので操作可能なリポジトリも決まっている(決める)。また、マージリクエスト自体はマージしてほしいURIを指定するだけなので、contributorのリポジトリはinternetから常にアクセス可能な状況にあることが必要となる。しかしたいていノートパソコンなんかで作業しちゃうので、ArXのmirrorコマンドを使って適当なサーバへmirrorしてからマージリクエストを発行することになるだろう。さもないと、他の人のマージリクエストなどで自分のリポジトリを参照することもあるので大変なことになる。

具体的には

があるが、それはまた後で。