가장 Emacs다운 Bzr 사가

• 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는 파일 복사·이동·이름 변경 정보를 명시적으로 받기 때문에 더 빨라야 할 것처럼 보인다고 봄
• 실제 수치에서도 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은 Git for ELPA, Bzr for trunk라는 두 도구 체제가 마음에 들지는 않지만 다른 출구가 없다고 봄
  • 그는 이 변경을 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.”이라는 여섯 단어 메시지를 보냄
• 이 전환은 일부에게 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에 머물러 있었던 시간이 있었음