mozilla-inbound

Mozillaのルールとして、WebKitとは違い、レビューが通ったコードはmozilla-centralに手動でチェックインしないといけなくて、なおかつそのチェックインで問題が発生しないかどうかをチェックインした人がウォッチしなければいけないという暗黙のルールがあった。ウォッチするってことは常にtinderbox (tbpl) をチェックしないといけなくて、自動テストの失敗はなんで失敗したかを調べなきゃいけなかった。で、たまにしかチェックインしない人だと、IRCで「なぜ起きるのか教えてくれ！」って叫ぶ声がよくあった光景だった。

で、Firefox 4が終わったくらいからそのルールをやめようとして、cedarを使ってチェックインをウォッチしないルールをehanあたりが作って、それが実運用された。それがmozilla-inbound。mozilla-inboundへのチェックインはツリーの状態（テストの結果）をウォッチしなくてもよくて、テストが失敗してそうな修正は、コビトさん(人間ね)が自動的にバックアウトするルールになった。また、定期的にmozilla-centralとの同期を（手動で）行うので、一般的なNightlyにはテストがちゃんとパスされたものが入り、Nighlyが不安定なことが減ったはず。

また、チェックイン前のテストでは、try serverと呼ばれるものを使うことで事前にテストを実行できる (要Level 1のチェックイン権限。try serverはchromiumにも導入されてるんだってのは最近知ったけど、MozillaかGoogleのどっちが最初にこのアイデア導入したかは知らない)。で、try serverではどのバイナリをビルドするかとか (Win32の場合は、VS2010でビルドするのもできる。現在のFirefoxはVS2005使ってるけどね)、どのテストを実行するかとかを選べる。TryChooserって呼んでるけど。

mozilla-centralへのマージをやってるのが数名 (EdとかMacroとか)で回してるので、祝日とかが多いと、mozilla-centralにまったくコードが入らないことが起きるんだよね。checkin-neededも同じようにDaoとかやってくれる人が決まってるので、彼らがいないと放置プレイになりがち。まぁ、もう少し自動化できるところは自動化しないとね。