▲

Mozilla Firefox 코드 저장소, Mercurial에서 GitHub로 이전

 (github.com/mozilla-firefox)
3P by GN⁺ 19시간전 | ★ favorite | 댓글 1개
  • 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⁺ 19시간전  [-]
Hacker News 의견
  • 나는 Mozilla에서 일하고 있지만 VCS 툴링이나 이번 전환에는 관여하지 않음, 추가 맥락을 주기 위함임. Firefox 코드의 공식 저장소가 최근에 hg.mozilla.org의 mercurial에서 GitHub로 옮겨졌음. 코드에만 영향이 있고, 이슈 트래킹은 지금도 bugzilla를, 코드 리뷰 및 랜딩은 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를 사용하는 주요 장점은 많은 사용자가 이미 계정이 있고 플랫폼에 익숙하다는 점인데, 이슈는 bugzilla에서만 받고 있어서 버그 제보 자체에도 장벽이 생김. bugzilla와 Firefox에 접근해 맥OS의 접근성 버그를 제보한 적이 있는데, 사이트 찾고 가입해 익혀야 해서 꽤 불편했음. 결국 버그는 확인됐지만 고쳐지지 않았음
  • Mozilla의 전략적 관점에서 이해할 수 있는 결정으로 보임. 구글에서 받는 수입이 줄어들고 인력도 줄여야 할지 모르지만, Firefox 개발을 계속하려면 커뮤니티의 더 많은 참여가 필요하고 GitHub가 가장 잘 알려진 개발자 플랫폼이므로 진입장벽이 낮아짐. GitHub 대신 GitLab 등을 활용하지 않는 것에 대해 불만을 가질 수 있으나, Firefox 개발이 계속되고 시장에 경쟁 엔진이 존재한다는 점에서 모두에게 이익임
    • GitHub를 못 쓴다고 기여를 포기하는 사람은 대부분 특별히 가치 있는 기여자라고 보지 않음. 예외는 있겠지만 직접 참여한 비사소 오픈소스 프로젝트에서는 본 적 없음. 오히려 진입장벽이 약간 높아지는 것이 저품질의 1회성 기여자를 거를 수 있는 긍정적 효과가 있다고 생각함
    • 나는 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에 있으며, 이슈는 버그질라에 남아있음. GitHub의 좋은 검색, 소스 브라우징, git의 친숙함 활용 가능함. 전 Firefox와 Thunderbird 기여자로서 mozilla-central 사이트에서 검색하는 것보다 로컬 검색을 훨씬 많이 썼음. 개발 중에는 IDE에서 검색하지만, 사이트에서 쉬운 검색이 새로운 기여자에겐 환영할 만한 요소임
    • 반대로 나는 searchfox가 사용해 본 최고의 코드 네비게이션 도구라고 생각함. 크로스-언어 네비게이션, 항상 켜진 블레임 등 기능이 많고, GitHub보다 훨씬 빠르고 가벼움. 이런 툴을 더 많은 프로젝트에서 쓸 수 있으면 좋겠고, 사라지면 아쉬울 것임
    • GitHub의 소스 브라우징 품질은 최근 들어 심각하게 저하됐다고 느낌. 비동기 로딩(js 필요), 네트워크 불안정시 깨짐, 페이지 내 검색도 망가짐. 최근의 이슈/PR 리뉴얼도 후퇴라고 생각하며, uBlock Origin을 쓰면 PR 검색이 불가함
  • 좋은 변화라고 보지만, 왜 기존 github.com/mozilla org가 아닌 새로운 org를 만들었는지 궁금함
    • 자세한 이유는 모르지만, 여러 부분에 있어 org별로 구분해야 하는 경우가 있고, 예를 들어 SSO는 org 전체에만 적용되므로 Firefox repo가 Mozilla 메인 repo와 전혀 다른 인증/유저 구성을 가질 수 있기 때문임
    • Mozilla는 여러 org가 있음
    • Conway’s Law 때문으로 추정됨
    • GitHub는 org나 repo 레벨만 있고 그 이상 레벨이 없음. 많은 설정(SSO, 접근권한, 공통 설정 등)이 org별로 적용돼, 보통 새 org를 만드는 게 깔끔한 해결책이지만, 불편함도 큼(Gitlab이라면 하나의 인스턴스나 org 안에 Firefox, 그 밖의 것 등 네임스페이스를 만들 수 있었음)
  • Mozilla같은 조직이 GitHub 같은 외부 호스팅을 쓰는 게 이상하게 느껴짐. 작은 1인 프로젝트는 이해하지만 기여자에게 외부 서비스 계정을 강요하는 건 친화적이지 않음
    • 오픈소스 프로젝트라면 모두에게 개방되고 기여하기 쉬운 환경과 가시성을 제공함으로써 긍정적이라고 생각함
  • 내가 기억하는 바로는 “master” 브랜치는 mozilla-central이었음. 지금은 “main”, “autoland”가 있는데 뭔지, 예전 mozilla-central과 동등한 브랜치가 뭔지 궁금함
    • 나는 Firefox 개발자는 아니지만, “main”이 mozilla-central과 같고, “autoland”는 예전에도 곁에 있던 브랜치로 커밋이 먼저 올라오는 곳임
  • bugzilla가 읽기 전용이라도 남아있길 바람. 웹이 “ad-hoc”으로 쌓여온 플랫폼이라, 과거의 많은 이유는 bugzilla에만 남아있음. 사라진 웹사이트나 브라우저가 특정 동작을 하게 만든 이유도 여기서만 확인 가능함
    • bugzilla는 여전히 Firefox의 버그 트래커임. 변경 계획은 없음. (GitHub 이슈는 사용되지 않음)
    • bugzilla는 훌륭했고, 시대를 앞선 제품이었음. 지금도 비슷한 수준의 자체 호스팅 버그 트래커는 없다고 생각함
답변달기