▲

가장 Emacs다운 Bzr 사가

 (thanosapollo.org)
2P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • 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에 머물러 있었던 시간이 있었음

함께 보면 좋은 글 β

▲
GN⁺ 11시간전  [-]
Lobste.rs 의견들

  • rms가 이끄는 프로젝트에서 일하면 정말 정신이 나갈 것 같음

    • 아, 이제 why-cooperation-with-rms-is-impossible.au 플래시백이 떠오름

  • 정말 굉장한 역사임. 오래전에 어느 대학에서 Mark Shuttleworth가 원래의 Bazaar를 설명하던 발표를 봤는데, 분산 버전 관리 시스템이라는 아이디어가 정말 흥미로웠음
    그 뒤 bzr 재작성판이 나왔고 완전히 빠져들었음. Git보다 훨씬 말이 된다고 느꼈고, 몇 년을 프로젝트에 쏟아부으며 메일링 리스트에서 활동하고 플러그인을 만들고, 코드 차이 비교 알고리즘을 C로 다시 작성해 더 빠르게 만들려고도 했음
    결국 Git이 승자라는 게 분명해졌지만, 받아들이는 데는 꽤 오래 걸렸음

  • 이 요약에 따르면 Richard Stallman은 2013년까지도 Emacs 프로젝트가 Git으로 이전하는 걸 금지했다고 함. 이후 2013년 말과 2014년 말에 Emacs가 두 단계로 Git으로 옮겼다고 나오지만, 2013년 초 이후 Stallman은 언급되지 않음
    수년 동안 Bazaar를 지지해 왔는데, 그 뒤 메일링 리스트 스레드에서는 정말 반대 글을 올리지 않았던 걸까? 아니면 그 사이 Emacs 프로젝트에 대한 권한을 잃은 걸까?
    글에 링크된 2014년 스레드에서는 그의 이름이 들어간 이메일을 못 봤지만, 링크되지 않은 다른 스레드가 있었을 수도 있음. 논란 때문에 Stallman이 뭔가에서 사임한 시기였나 싶었지만 아니었고, 내가 다른 일을 떠올린 것이었음. Wikipedia에 따르면 Stallman은 2019년에 Free Software Foundation을 떠났고, GNU Project를 떠난 것도 아니었음

  • 어떤 프로젝트가 공식 GNU 프로젝트가 되는지 정확히 모르겠음. 라이선스 때문인가? Git과 Linux는 둘 다 GPLv2-only이고 Bazaar는 GPLv2+임. 저작권 양도 때문인가? 저장소, 이슈 추적기, 메일링 리스트 등의 호스팅 때문인가? 지지처럼 작동하는 “GNU” 접두사 이름 때문인가?
    어딘가 중요한 구분이 있는 건 분명해 보이지만, 그게 무엇이고 왜 중요한지는 잘 모르겠음
    그리고 반복되는 하나 차이 오류도 있음:

    On November 13th, ESR posted a seven-word message:

    Commits are open. Have at it.

    [...]

    Six years of debate, [...] and it ended with seven words.
    아, 대칭을 맞출 절호의 기회를 놓쳤음

  • 2014년쯤 mysql에 뭔가 하려고 했는데, 저장소를 복제하고 릴리스 브랜치를 체크아웃하는 데만 하루 종일 실패하다 포기했던 일이 이제 훨씬 덜 부끄러워짐
    그 전까지 CVS, Subversion, Mercurial을 몇 년씩 써 왔기 때문에 네트워크나 내 컴퓨터 문제라고 생각했음. 이 글을 읽기 전까지는 bzr의 실제 벤치마크가 그렇게 끔찍했는지, Canonical이 bzr을 그렇게 많이 쓰면서도 이미 bzr 팀을 해고했는지 몰랐음
    몇 년 뒤 mysql에 다른 일을 하러 갔을 때는 Git으로 옮겨져 있었고, 시작도 하기 전에 막히지 않은 덕분에 흥미로운 작업을 해낼 수 있었음

    Since I had no interesting books to read today, nor interesting films to watch, I decided to scavenge for the most intriguing content one can find online. I ended up reading the Linux kernel mailing lists, but those discussions seemed to be 18+, so I settled for the comparatively civil emacs-devel.
    지금까지 본 것 중 가장 훌륭한 “아니요, 이 글은 AI로 쓰지 않았습니다” 면책 문구임

  • 멋진 글임. 이런 메일링 리스트 드라마가 어떻게 흘러갔는지 늘 보고 싶었지만 직접 뛰어들 용기는 없었음. 이야기 구성과 발췌가 정말 좋음

  • 혼란스러운 역사를 재미있게 정리했음. 다만 제목은 “The Most Emacs Bzr Saga”보다 “The Most Bzr Emacs Saga”가 맞지 않나 싶음
    “Emacs”를 형용사처럼 쓰는 일이 전혀 없진 않겠지만 그래도 좀 어색함

  • Bazaar가 내가 처음 써 본 버전 관리 시스템이었음. 당시 Ubuntu로 Linux에 입문하던 중이었고, Canonical은 소스 코드를 호스팅할 수 있는 Launchpad를 쓰고 있었음
    그 전까지는 코드를 어디에도 올리지 않았는데, Launchpad와 Bazaar를 쓰니 꽤 멋져 보였음. 물론 내 프로젝트들은 너무 작아서 성능 문제를 전혀 느끼지 못했음

답변달기