Mozilla Firefoxのコードリポジトリ、MercurialからGitHubへ移行

• Firefoxは最近、メインリポジトリをMercurialからGitHubへ移行した
• バグ追跡はBugzilla、コードレビューはPhabricator、CIはTaskclusterを引き続き使用している
• 現在はGitHubが中心リポジトリだが、MercurialサーバーもGitHubから同期されて維持されており、既存の自動化システムも段階的にGitへ移行する予定
• CIテスト用のtryリポジトリは依然としてMercurialベースだが、徐々に抽象化レイヤーの背後に隠されつつあり、今後Gitへ移される予定
• Gitを標準で使えるようになったことで、新しいコントリビューターはMercurialを別途学ぶ必要がなく、Gitだけ習得すればよいという利点が生まれた
  • 以前はgit cinnabarという拡張機能をインストールする必要があったが、今では標準のGitだけで十分
• 既存のMercurialのmozilla-centralはGitでは**mainブランチ**に変更され、autolandブランチはGitでもそのままautoland
• GitHubのPRベースのワークフローは現時点では導入されておらず、今回の変更には含まれていない。将来的な可能性はあるが、公式な計画はない
• MozillaはGitHubへの移行を通じて、自前のVCSインフラ運用負担を減らせる
• 大規模プロジェクトに求められる性能、安定性、可用性を自前で提供するためのコストと複雑さを減らすことが主な目標

git-cinnabarの作者Glandiumによる詳細な経緯と説明: How I (kind of) killed Mercurial at Mozilla

> Mozilla、FirefoxコードリポジトリをGitHubへ移行しMercurial時代に幕

• MozillaはFirefox開発の中心VCSをMercurialからGitへ移行し、GitHubを公式リポジトリとすることを決定した
• この決定の背景には、git-cinnabarという拡張ツールの長期的な開発と普及があり、これによりGitユーザーもMercurialリポジトリへスムーズにアクセスできていた
• Mercurialのブランチ構造の問題、リポジトリ規模の拡大、自前サーバー運用の負担などが複合的に作用し、自前インフラ維持の難しさが積み重なっていた
• GitHubの選択には議論もあるが、Mozilla内部の数千のリポジトリがすでにGitHub上に存在するなど、コントリビューターの使いやすさと実用性の面で避けがたい選択だった
• git-cinnabarはMozilla内部の必要性から始まった個人的なサイドプロジェクトだったが、今後の移行期においても重要なツールとして引き続き維持される可能性が高い
  > 「私が火をつけたわけではないが、その火に油を注いだのは事実だ。」

[GN⁺]

Hacker Newsの意見

• 私はMozillaで働いていますが、VCSツーリングや今回の移行には関わっていません。補足の文脈を共有するために書きます。Firefoxコードの公式リポジトリは最近、hg.mozilla.orgのMercurialからGitHubへ移されました。影響があるのはコードのみで、課題管理は今もbugzilla、コードレビューとlandingはPhabricator、CIはtaskclusterシステムを引き続き使っています。短期的にはMercurialサーバーはGitHubと同期されており、自動化システムが徐々にgitバックエンドへ移行できるようにしています。Mercurialは今でも「try」リポジトリ（WIPパッチに対してCIを回す場所）で使われていますが、次第に抽象化レイヤーの裏に隠されつつあり、これも後で移行される予定です。以前のリポジトリに慣れている人向けに言うと、「mozilla-central」はgitの標準ブランチ名である「main」に、「autoland」は「autoland」ブランチにマッピングされます。もともとgitだけでFirefoxに貢献することもできましたが、git cinnabarという拡張のインストールが必要でした。hgを学ぶか、git+拡張を使うかの選択は新規コントリビューターにとって参入障壁になっており、多くの場合はgitは知っていてもMercurialは知らない状態でした。今ではもう悩む必要はありません。git cinnabarの作者であるglandiumが、移行発表時に詳細な文脈と理由をブログに書いています。短期的にはコントリビューターの立場から見ると、ほとんど変化はありません。通常のgit利用がデフォルトのワークフローになり、それ以外は変わっていません。将来的にはGitHub PRベースのワークフローのサポートが入るかもしれませんが、この変更には含まれていません。バックエンドでは、移行が終わればMozillaは自前のVCSインフラを運用するための時間と労力を減らせますし、この規模のプロジェクトに必要な性能と可用性を満たすのはかなりの挑戦です
  • 個人的には、MozillaがMicrosoft所有のクローズドなプラットフォームへ移るという決定は正しくないと思います
  • Phabricatorは開発終了していますが、代替の計画があるのか気になります。Phorgeのようなものを検討しているのか聞いてみたいです
  • 補足の文脈をありがとうございます。自前ホスティングのソリューションで直面した主なスケール上の問題が何だったのか気になります
  • GeckoViewとMozilla Android ComponentsもGitHubへ移されるのか聞いてみたいです
  • コードだけがGitHubへ移され、課題管理がbugzillaに残ったままなのは残念です。GitHubを使う大きな利点は、多くの人がすでにアカウントを持っていてプラットフォームに慣れていることですが、issueはbugzillaでしか受け付けないので、バグ報告自体にも障壁が生まれます。bugzillaとFirefoxにアクセスしてmacOSのアクセシビリティバグを報告したことがありますが、サイトを探して登録し、使い方を覚える必要があってかなり不便でした。最終的にバグは確認されましたが、修正はされませんでした
• Mozillaの戦略的な観点からは理解できる決定に見えます。Googleからの収入が減り、人員削減も必要になるかもしれませんが、Firefox開発を続けるにはコミュニティのより多くの参加が必要で、GitHubは最もよく知られた開発者プラットフォームなので参入障壁が下がります。GitHubではなくGitLabなどを使わないことに不満を持つ人はいるかもしれませんが、Firefox開発が継続し、市場に競争するエンジンが存在し続けることは、みんなにとって利益です
  • GitHubが使えないからといって貢献を諦める人は、たいてい特に価値のあるコントリビューターではないと思います。例外はあるでしょうが、自分が直接関わった非自明なオープンソースプロジェクトでは見たことがありません。むしろ参入障壁が少し高いほうが、低品質な一回限りのコントリビューターをふるい落とすという良い効果があると思います
  • 私はghとPhabricatorの組み合わせが理解できず、Firefoxにパッチで貢献するのを完全に諦めました。両者がどう連携するのか理解できず、ブランチ/PRをどう更新すべきかも分からなくて、結局試すこと自体をやめました
  • GitLabに関する個人的な経験では、数年前にGitLabは大規模オープンソースプロジェクトのホスティングにあまり関心がないことを明確にしており、FOSS対応もオープンソースプログラム経由でしかできませんでした。このプロセスは複雑で追加要件も多く、Mozillaでは受け入れにくいはずです。たとえばGitLabを使うには、そのオープンソースプロジェクトがGitLab FOSS版を修正・複製する権利を放棄しなければならず、これはどのプロジェクトにとっても重大な問題です。もしかすると弁護士が定型条項を入れた結果そうなっただけかもしれませんが、それだけでも大きな問題だと分かります。なのでGitLabは除外です。Codebergなどは残りますが、新しいコントリビューターの参入障壁を下げるには、たいていすでに登録してあるGitHubが適しています
  • GitHubへの移行は技術的な変化ですが、実際の核心はMercurialからgitへの移行であり、社会的な考慮が技術的な決定に影響したのだろうと推測します
  • 参入障壁を越えられない人は、バグ報告すらすべきでないし、コード修正についても同じだという考えです
• Firefoxへの貢献における主要な技術的負債が解消されたのは良いことです。数年前に試したとき、Mercurialはリポジトリのクローンに何時間もかかり、公式のgitサポートもなかったため、まともに作業するには非公式のgitサポートを使う必要がありました。当時はドキュメントもひどく、無駄にすべてを再ビルドさせられました
• どうして既存のmozilla orgではなくmozilla-firefox orgを選んだのか気になります
  • アクセスルールが違うからか、あるいは既存orgと分離して自動化が他の場所に影響するのを防ごうとしたのだと思います
  • 本当に良い質問だと思います
• 「Firefox Moves to GitHub」の出典が何なのか気になります。単なるミラーかもしれません。LinuxにもGitHub上のミラーがあります。（後で編集: 出典を追加）
  • 私も同じことを考えました。実際、GitHubに設定されているワークフローは、PRを定型の返信とともに閉じることだけです
• Firefox Mobile（Fenix）は以前GitHubを使っていましたが、少し前にMozillaのMercurial mozilla-centralリポジトリへ移行しました。今ではデスクトップ版とモバイル版の両方がGitHub上にあり、issueはBugzillaに残っています。GitHubの優れた検索、ソースブラウジング、gitの親しみやすさを活用できます。元FirefoxおよびThunderbirdのコントリビューターとして、私はmozilla-centralサイトで検索するより、ローカル検索をはるかに多く使っていました。開発中はIDEで検索しますが、サイト上で簡単に検索できることは新しいコントリビューターにとって歓迎すべき要素です
  • 逆に私は、searchfoxはこれまで使った中で最高のコードナビゲーションツールだと思います。クロス言語ナビゲーション、常時有効なblameなど機能が豊富で、GitHubよりずっと高速で軽量です。こうしたツールをもっと多くのプロジェクトで使えたらいいですし、なくなってしまうなら残念です
  • GitHubのソースブラウジング品質は最近かなり低下したと感じます。非同期ロード（js必須）、ネットワークが不安定だと壊れる、ページ内検索も壊れている。最近のissue/PRのリニューアルも後退だと思いますし、uBlock Originを使うとPR検索ができません
• 良い変化だとは思いますが、なぜ既存のgithub.com/mozilla orgではなく新しいorgを作ったのか気になります
  • 詳しい理由は分かりませんが、いくつかの点でorgごとに分ける必要がある場合があります。たとえばSSOはorg全体にしか適用できないので、Firefox repoはMozillaのメインrepoとはまったく異なる認証/ユーザー構成を持つ必要があるのかもしれません
  • Mozillaには複数のorgがあります
  • Conwayの法則が理由だと推測します
  • GitHubにはorgレベルかrepoレベルしかなく、その上の階層がありません。多くの設定（SSO、アクセス権、共通設定など）はorg単位で適用されるため、通常は新しいorgを作るのがすっきりした解決策ですが、不便さも大きいです（GitLabなら、1つのインスタンスやorgの中にFirefoxやその他のネームスペースを作れたでしょう）
• Mozillaのような組織がGitHubのような外部ホスティングを使うのは奇妙に感じます。小さな1人プロジェクトなら理解できますが、コントリビューターに外部サービスのアカウントを強制するのはフレンドリーではありません
  • オープンソースプロジェクトであれば、誰にでも開かれ、貢献しやすい環境と可視性を提供することで前向きだと思います
• 私の記憶では、「master」ブランチがmozilla-centralでした。今は「main」と「autoland」がありますが、それぞれ何で、昔のmozilla-centralに相当するブランチがどれなのか気になります
  • 私はFirefox開発者ではありませんが、「main」がmozilla-centralと同じで、「autoland」は以前から横にあったブランチで、コミットが先に上がる場所です
• bugzillaが読み取り専用でも残ってくれることを願います。Webは「ad-hoc」に積み上がってきたプラットフォームなので、過去の多くの理由はbugzillaにしか残っていません。消えてしまったWebサイトやブラウザが特定の動作をするようになった理由も、ここでしか確認できません
  • bugzillaは今でもFirefoxのバグトラッカーです。変更の予定はありません。（GitHub issueは使われません）
  • bugzillaは素晴らしく、時代を先取りした製品でした。今でも同等レベルのセルフホスト型バグトラッカーはないと思います