最もEmacsらしいBzrのサーガ
(thanosapollo.org)- 2008年、EmacsはCVSの後継候補として Git と Bazaar を検討し、ベンチマークではGitが圧倒的に高速だった
- Richard Stallmanは、Bazaarが GNUパッケージ であることを理由に採用を決定し、技術的な議論ではその決定は覆らなかった
- 2008〜2012年にGitHubが成長する一方で、Emacsのコントリビューターは Bazaar を学ばなければならず、Canonicalは2012年に開発チームを解雇した
- 2013年、Bazaarの保守停滞と ELPAブランチ のバグが再議論を引き起こし、ELPAは最終的にGitへ移行した
- 2014年、Eric S. Raymondの移行作業を経てEmacsは Git に移ったが、その直後に中核コントリビューターたちのGit学習の問題が表面化した
2008年: Gitは速かったがBazaarが選ばれた
- 2008年3月、Emacsは CVS からよりモダンなバージョン管理ツールへ移行しようとし、候補は Git と Bazaar に絞られた
- GitはLinus TorvaldsがLinuxカーネルのために作ったツールだった
- BazaarはCanonicalが保守していたGNUプロジェクトだった
- emacs-develでは 236件のメッセージ に及ぶ議論が続き、複数の開発者が両ツールをベンチマークした
- Andreas Schwab は、
bzr logの起動に1分以上かかり、「完全に使い物にならないほど遅い」と評価した - David Kastrupは、
git logがほぼ即時に実行される一方で、Bazaarはファイルのコピー・移動・リネーム情報を明示的に受け取るため、もっと速いように見えるはずだと述べた
- Andreas Schwab は、
- 実測値でも Git優勢 は明白だった
git log | head -1は 0.012秒、同じ操作をBazaarで実行すると 21.5秒 だった- 単一ファイル変更のコミットはGitが 0.08秒、Bazaarが 17秒 だった
- 当時の筆頭メンテナーだった Stefan Monnier は、BazaarがGitより速いか遅いか自体は核心ではないが、Emacsが移行するには「十分に速い」必要があり、少なくとも
bzr diffに数秒以上かかってはならないと考えていた - CanonicalのBazaar開発者 Jonathan Lange は、初回チェックアウトのために
wget、tar、bzr init-repo、bzr branch、bzr pull --rememberを組み合わせた手順を提案した- この手順は
git cloneと対照的なほど長く手動的だった
- この手順は
GNUツールを使うべきだという決定
- ある人がEmacsのメンテナーと意思決定者に、「現時点でbzrが適切なツールではないと説得するには、さらにどんな情報が必要か」と尋ねた
- Richard Stallmanは、この選択は現在この瞬間だけの決定ではなく 長期的な決定 であり、後で覆しにくい暫定判断をするより、Bazaar開発者が改善するまで数か月待つほうがよいと答えた
- Stallmanは別のメッセージで、「この件は終わっており、決定済みだ。GNU Bzrを使う。それがGNUパッケージだからだ」と明言した
- 技術的な論拠が政治的な決定によって消されているという問題提起に対し、Stallmanは GNUパッケージ同士が相互に支え合うルール がGNUシステム全体をより良く機能させると答えた
- 「GitをGNUシステムの一部にできないのか」という問いには、GitをGNUシステムに含めること自体は可能だが、Git開発者がGitをGNUパッケージにしたがる可能性は低いと見ていた
- 2008年のベンチマーク、236件のメッセージ、Canonical社員による回避的な手順があっても結論は変わらず、Emacsは GNUパッケージ であることを理由にBazaarを選んだ
2008〜2012年: Git普及とBazaar利用の負担
- 2008年にGitHubが立ち上がって急成長する中、Emacsのコントリビューターはパッチを提出するために、他では使わない Bazaar を学ばなければならなかった
- emacs-develにはBazaarの問題を扱うスレッドが繰り返し登場した
- “Help me unstick my bzr, please”
- “Can NOT bzr the emacs repos (may be bzr has a memory leak)”
- 2012年、Canonicalは Bazaar開発チームを解雇 した
- その後、Bazaarの保守状況はEmacs開発プロセスにおいてさらに大きな負担になった
2013年: 保守停滞とGit再議論
- 2013年3月、Bazaar開発が事実上止まってから1年後、John Wiegley はEmacsをGitへ移行できるか再び問いかけた
- Bazaar開発は事実上停滞状態だった
- ELPAリポジトリのようにEmacs開発に影響する重要なバグが、何年もバグトラッカーに残ったまま解決されていなかった
- この議論でも約 200件のメッセージ が続いた
- Stallmanの最初の反応は、Bazaarメンテナーがいくつかのバグを修正しており、自分も前日にELPAブランチのバグ修正を依頼したばかりなので、妥当な時間を与えたいというものだった
- Dmitry Gutov は、そのバグは 1.5年前からあるバグ なのに遅すぎるのではないかと問い返した
- Stallmanは、Bazaarが有効に保守されているかを判断しようとしている と述べ、「Yes」という答えを得たいと明かした
- Joakim Verona は、Bazaarコミュニティは非常に親切だが、よく知られたバグやパッチが多く、その一部はEmacs開発者が提供したものなのに何年もupstreamに取り込まれていないと述べた
- Stallmanは、Bazaarのメーリングリストを読む時間はない とし、自分が読んでいる開発メーリングリストはemacs-develだけだと答えた
- BazaarユーザーがBazaarの保守十分性の判断に発言権を持つべきかという問いには、関連情報は参考にするが、ユーザーに「発言権」を与えるのは不適切だと考えていた
Karl Fogelの批判と委任の問題
- Producing Open Source Software の著者であり、初期Subversion開発者の一人でもあるKarl Fogelは、Stallmanの判断の仕方と委任の欠如を批判した
- Fogelは、StallmanにBazaar開発状況を詳細に見る時間がないなら、Bazaarが今なおEmacsにとって良い選択かどうかを有能に判断するのも難しいと考えた
- 彼は、そのような評価に割く時間と精神的余力がないなら Emacsメンテナーに委任 すべきだと主張した
- Fogelは、一人に一つのバグについて尋ねるやり方では、プロジェクトの健全性を測る代理指標にはなりえず、スレッドの他の人たちはすでにもっと徹底した調査をしていると述べた
- Stallmanは、「Emacsよりもさらに多くのものが懸かっているからだ」と答えた
- GNUの代表的プロジェクトがGNUツールを捨てた場合、それが他のGNUパッケージにどんなシグナルを送るかが核心的な論点だった
- Fogelは、StallmanがBazaarの保守状況を信頼できるだけ評価する時間を使うか、そうできる人に委任するよう改めて求めた
- Stallmanは、すでに計画があり実行中だと答えるだけで、具体的な内容や日程、委任は示さなかった
ELPAが先にGitへ移行
- 2013年の議論でStefan Monnierは、Bazaarを使い続けるにせよ、Git、Monotone、Darcs、Mercurial、OpenCM、Fossilなどへ変えるにせよ、大きな関心はないと述べた
- Stefanにとって当面重要だったのは ELPAブランチ をBazaarから切り離すことだった
- BazaarがELPAブランチを正しく扱えなかったためだ
- Leo Liuは、GNUプロジェクトの大半はBazaarを使っていないと指摘した
- 彼は、Bazaarのバグを直すことはBazaarには利益でも、GNU全体には損失になりうると考えた
- ボランティアの余暇時間の20%がBazaarと格闘することに費やされるなら、GNUプロジェクトへの参加をためらわせるほどコストが大きいという論理だった
- その年の末、Stefan MonnierはBazaarで壊れていた ELPAブランチ をGitへ移した
- ELPAブランチにはチェックアウト中に衝突するバグがあり、それを直せる人がもう残っていなかった
- Stefanは、ELPAにはGit、trunkにはBzrという二重ツール体制は好ましくないが、他に出口がないと考えていた
- 彼は、この変更をGitとBazaarの長短をめぐる議論や
trunkのGit移行論に広げないよう釘を刺した
- ELPAがGitへ移ったことで、「ELPAにGitで十分ならtrunkにも十分ではないか」という次の議論の足場ができた
2014年: Eric S. Raymondの移行作業と実際の移行
- 2014年8月、Eric S. RaymondはEmacsリポジトリ移行用のスクリプトを準備済みだった
- 彼は、難しい作業はすべて終わっており、ボタンを押す前に必要なのは約8時間の通知だけだと述べた
- 実際の移行は 2014年11月 に行われた
- 11月13日、ESRは “Commits are open. Have at it.” という6語のメッセージを送った
- この移行は一部の人々に heroic と表現された
- 2008年の236件のメッセージ、2013年の200件のメッセージ、Stefanの保守作業、繰り返されるBazaar問題、死んだバージョン管理システムを経て、EmacsはGitへ移った
移行後: 中核コントリビューターたちもGitを新たに学ぶ必要があった
- 移行直後の数日間で、中核コントリビューターのかなりの人数がGitを使ったことがないと判明した
- emacs-develにはGitの使い方を尋ねるスレッドが続いた
- “This Is The Git Help Mailing List”
- “git pull fails with merge conflicts. How can this possibly happen?”
- “A simple git workflow for the rest of us”
- “need help adjusting workflow to git”
- “Good book on Git”
- “Obscure error/warning/information message from git pull” は 124件のメッセージ に及んだ
- 重要なテキストエディタを長年開発してきた人々が基本的なGitの質問をするようになった背景には、他の世界がGitへ移っていくあいだEmacsがBazaarにとどまっていた年月があった
1件のコメント
Lobste.rsの反応
rms が率いるプロジェクトで働いたら、本当に気が狂いそう
本当にすごい歴史だ。ずっと前に、ある大学で Mark Shuttleworth が元祖 Bazaar を説明する講演を見たことがあるが、分散バージョン管理システムという発想が本当に興味深かった
その後 bzr の書き直し版が出て、完全に夢中になった。Git よりずっと筋が通っていると感じて、何年もそのプロジェクトに注ぎ込み、メーリングリストで活動し、プラグインを作り、コード差分比較アルゴリズムを C で書き直して高速化しようとまでした
結局は Git が勝者 だということが明らかになったが、それを受け入れるまでにはかなり時間がかかった
この要約によると、Richard Stallman は 2013 年までも Emacs プロジェクトが Git に移行するのを禁じていたらしい。その後 2013 年末と 2014 年末に Emacs は 2 段階で Git に移ったとあるが、2013 年初頭以降 Stallman への言及はない
何年も Bazaar を支持してきたのに、その後メーリングリストのスレッドでは本当に反対意見を投稿しなかったのだろうか？ それともその間に Emacs プロジェクトに対する権限を失ったのだろうか？
記事にリンクされている 2014 年のスレッドでは彼の名前入りのメールは見当たらなかったが、リンクされていない別のスレッドがあったのかもしれない。騒動のせいで Stallman が何かを辞任した時期だったかと思ったが、そうではなく、私が別の出来事と混同していただけだった。Wikipedia によれば、Stallman が Free Software Foundation を離れたのは 2019 年で、GNU Project を離れたわけでもなかった
どういうプロジェクトが公式の GNU プロジェクト になるのか、正確にはわからない。ライセンスの問題なのだろうか？ Git と Linux はどちらも GPLv2-only で、Bazaar は GPLv2+ だ。著作権譲渡の問題だろうか？ リポジトリ、Issue トラッカー、メーリングリストなどのホスティングの問題だろうか？ 後押しのように機能する「GNU」接頭辞つきの名前の問題だろうか？
どこかに重要な線引きがあるのは確かそうだが、それが何で、なぜ重要なのかはよくわからない
それと、繰り返し出てくる 1 つ違いの数え間違い もある:
2014 年ごろ、mysql で何かしようとして、リポジトリを clone してリリースブランチを checkout するだけで丸一日失敗し続けて、結局諦めたことがあったが、今となってはずっと恥ずかしくなくなった
それまでは CVS、Subversion、Mercurial を何年も使っていたので、ネットワークか自分のマシンの問題だと思っていた。この記事を読むまでは、bzr の実際のベンチマークがそこまでひどかったことも、Canonical が bzr をあれほど使っていながらすでに bzr チームを解雇していたことも知らなかった
数年後、mysql で別の仕事をしに行ったときには Git に移行していて、始める前から詰まることがなかったおかげで、面白い作業ができた
すばらしい記事だ。こういう メーリングリストのドラマ がどう展開したのかはいつも見てみたかったが、自分で飛び込む勇気はなかった。構成と抜粋が本当に良い
混乱した歴史を楽しくまとめている。ただ、タイトルは “The Most Emacs Bzr Saga” より “The Most Bzr Emacs Saga” の方が正しいのではないかと思う
“Emacs” を形容詞のように使うことがまったくないわけではないが、それでも少し不自然だ
Bazaar は、私が最初に使った バージョン管理システム だった。当時 Ubuntu で Linux に入門したばかりで、Canonical はソースコードをホストできる Launchpad を使っていた
それまではコードをどこにも上げていなかったが、Launchpad と Bazaar を使うとかなり格好よく見えた。もちろん自分のプロジェクトはどれも小さすぎて、性能問題はまったく感じなかった