PEP 481 – CPython을 Git, Github, Phabricator로 이전

Author:: Donald Stufft <donald at stufft.io>
Status:: Withdrawn
Type:: Process
Created:: 29-Nov-2014
Post-History:: 29-Nov-2014

Table of Contents

초록
근거
비판
예시: Scientific Python
참고 문헌
Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

Note

이 PEP는 철회되었습니다. Github으로의 이전을 문서화한 PEP를 찾고 계신다면 GitHub로의 이전을 문서화한 내용은 PEP 512를 참고하십시오.

이 PEP는 CPython과 이를 지원하는 저장소들의 저장소 호스팅을 Git과 Github으로 이전할 것을 제안합니다. 또한 변경 사항 리뷰를 처리하기 위해 GitHub 풀 리퀘스트의 대안으로 Phabricator를 추가할 것을 제안합니다. 이 PEP는 PEP 474 및 PEP 462의 대안으로 제시됩니다. 두 PEP는 전반적으로 같은 이점을 얻는 것을 목표로 하지만, Mercurial을 지원하며 완전한 오픈 소스인 도구로만 범위를 한정합니다.

근거

CPython은 많은 자원봉사자가 기꺼이 내어 주는 시간에 의존하는 오픈 소스 프로젝트입니다. 오픈 소스 프로젝트로서 CPython은 충분한 인력을 계속 확보하기 위해 기존 자원봉사자를 유지하는 것뿐만 아니라 새로운 자원봉사자를 끌어들이는 데에도 의존합니다. 프로젝트가 활용할 수 있는 인력을 늘리는 것에 더해, 현재 활용할 수 있는 인력을 효과적으로 사용할 수 있도록 하는 것도 필요합니다.

CPython 프로젝트의 현재 도구 체인은 맞춤형이자 독특한 도구 조합으로, 오래된 프로젝트들에서 흔히 볼 수 있는 것과 비슷한 워크플로를 강제하지만, 이러한 워크플로는 시간이 지날수록 점점 인기를 잃고 있습니다.

CPython 도구 체인과 워크플로가 이 프로젝트에만 있는 일회성이라는 점은, 새로운 기여자라면 누구나 CPython에 기여를 시작하기 전에 도구와 워크플로를 익히는 데 시간을 들여야 한다는 것을 의미합니다. 새로운 기여자가 CPython 워크플로를 익히는 과정을 거친 뒤에도, 그 지식을 앞으로 기여하고 싶은 다른 프로젝트에 가져가 적용할 수 있을 가능성은 낮습니다. 이는 기여를 가로막는 장벽으로 작용하여 잠재적인 새 기여자들을 쫓아내게 됩니다.

게다가 CPython이 사용하는 도구는 제대로 유지 보수되지 않고 낡았으며, 커미터가 변경 사항을 리뷰하고 승인할 때 시간을 더 효과적으로 쓸 수 있게 해 주는 중요한 기능이 부족합니다. 제대로 유지 보수되지 않는다는 것은 버그가 (고쳐지기라도 한다면) 더 오래 남아 있을 가능성이 높고, 장시간 서비스가 중단될 가능성도 더 높다는 것을 의미합니다. 낡았다는 것은 현대 웹 플랫폼의 기능을 효과적으로 활용하지 못한다는 것을 의미합니다. 마지막으로, 커밋 사전 테스트나 자동 병합 도구가 없는 것과 같이 몇 가지 중요한 기능이 부족하다는 것은, 커미터가 가장 단순한 변경 사항을 커밋할 때조차 불필요한 잡무를 해야 한다는 것을 의미합니다.

버전 관리 시스템

가장 먼저 내려야 할 결정은 주 서버 측 저장소의 VCS입니다. 현재 CPython 저장소와 여러 지원 저장소는 Mercurial을 사용합니다. VCS를 평가할 때는 VCS 자체의 기능뿐만 아니라 그 VCS를 둘러싼 커뮤니티의 네트워크 효과와 인지도도 고려해야 합니다.

이에 대한 실질적인 선택지는 Mercurial과 Git 두 가지뿐입니다. 두 시스템의 기술적 역량은 대체로 동등합니다. 이러한 이유로 이 PEP는 VCS 시스템에 관한 기술적 논거(인자)는 대체로 다루지 않고, 대신 사회적 측면에 초점을 맞춥니다.

특정 VCS를 사용하는 프로젝트나 사람의 수를 정확히 파악하는 것은 불가능하지만, 프로젝트들이 어떤 VCS를 사용하는지에 대한 여러 정보원을 살펴봄으로써 이를 추론할 수 있습니다.

The Open Hub(이전 명칭 Ohloh)의 통계 [1]에 따르면 The Open Hub가 색인한 저장소 중 37%가 Git을 사용하고 있으며(48%인 SVN에 이어 2위), Mercurial은 2%에 불과합니다(1%인 bazaar만 앞섬). 즉 The Open Hub에서 Git은 Mercurial보다 18배 남짓 더 인기가 있습니다.

여러 VCS의 인기도를 알 수 있는 또 다른 정보원은 PyPI 자체입니다. 이 정보원은 Python용으로 개발된 프로젝트를 나타내므로 Python 커뮤니티 자체에 더 초점이 맞춰져 있습니다. 안타깝게도 PyPI에는 이 정보를 나타내는 표준 위치가 없으므로 수작업으로 처리해야 합니다. 검색 범위를 PyPI의 상위 100개 프로젝트(다운로드 수 기준 정렬)로 한정하면, 그중 62%는 Git을, 22%는 Mercurial을, 13%는 그 밖의 것을 사용한다는 것을 알 수 있습니다. 이에 따르면 PyPI 상위 100개 프로젝트에서 Git은 Mercurial보다 3배에 조금 못 미칠 만큼 더 인기가 있습니다.

이 수치로 보아 오픈 소스 프로젝트에서는 Git이 단연 더 인기 있는 DVCS임이 분명하며, 더 인기 있는 VCS를 선택하면 여러 가지 긍정적인 이점이 있습니다.

새 기여자에게는 다른 프로젝트에서 작업하면서 이미 Git의 기초를 익혔을 가능성이 높아지고, 지금 막 Git을 배우는 중이라면 그 지식을 다른 프로젝트에도 적용할 수 있을 가능성이 높아집니다. 또한 커뮤니티가 더 크다는 것은 Git에 관한 사용법 안내서를 쓰고, 질문에 답하고, 글을 쓰는 사람이 더 많다는 뜻이며, 이 덕분에 새 사용자가 배우려는 도구에 관한 답과 정보를 더 쉽게 찾을 수 있습니다.

또 다른 이점은 커뮤니티가 더 크다는 특성상 그 주변에 더 많은 도구가 만들어진다는 것입니다. 이로써 GUI 클라이언트, 보조 스크립트, 저장소 호스팅 등 모든 면에서 선택지가 늘어납니다.

저장소 호스팅

이 PEP는 GitHub 풀 리퀘스트 제출을 허용할 것을 제안하지만, GitHub에는 GitHub에 호스팅되지 않은 저장소를 대상으로 풀 리퀘스트를 제출할 방법이 없습니다. 이 PEP는 또한 GitHub 풀 리퀘스트 외에 Phabricator의 Differential 앱으로도 변경 제안을 제출할 수 있도록 할 것을 제안하며, Phabricator는 Phabricator에 호스팅되지 않은 저장소를 대상으로 변경을 제출하는 것을 실제로 허용합니다.

이러한 이유로 이 PEP는 GitHub를 저장소의 정식 위치로 사용하고 Phabricator에 읽기 전용 미러를 두는 방안을 제안합니다. 향후 어느 시점에 GitHub를 더 이상 원하지 않게 되면, 저장소 호스팅을 Phabricator로만 쉽게 옮기고 GitHub 풀 리퀘스트를 받는 기능은 없앨 수 있습니다.

저장소를 GitHub에 호스팅하는 것에 더해, 모든 저장소의 읽기 전용 사본을 PSF 인프라에도 미러링합니다.

코드 리뷰

현재 CPython은 Google App Engine에서 실행되지 않도록 수정한 Rietveld의 자체 포크를 사용하고 있는데, 현재 이를 유지 관리할 수 있는 사람은 사실상 한 명뿐입니다. 게다가 많은 현대적인 코드 리뷰 도구에 있는 기능들이 빠져 있습니다.

이 PEP는 변경을 제안하고 코드를 리뷰하는 데 GitHub 풀 리퀘스트와 Phabricator 변경을 모두 허용할 것을 제안합니다. 둘 다 제안하는 이유는 기여자가 변경을 제출하기에 가장 좋은 도구를 고를 수 있고, 리뷰어는 가장 선호하는 도구에서 변경 리뷰에 집중할 수 있도록 하기 위해서입니다.

GitHub 풀 리퀘스트

GitHub는 매우 인기 있는 코드 호스팅 사이트이며, 사람들이 프로젝트에 기여하려 할 때 가장 먼저 찾는 곳이 점점 더 되어 가고 있습니다. 사용자가 GitHub를 통해 기여할 수 있게 하는 것은 기여자가 이미 익숙할 가능성이 높은 도구로 기여할 수 있게 하는 것이며, 익숙하지 않더라도 그 경험을 다른 프로젝트에 적용할 수 있을 가능성이 높습니다.

GitHub 풀 리퀘스트는 예전의 “버그 트래커에 패치 제출” 방식에 비해 상당히 큰 장점이 있습니다. 개발자가 표준 VCS 도구를 사용하여 완전히 자신의 VCS 안에서 작업할 수 있으므로, 패치 파일을 만들고 이를 어디에 올려야 하는지 알아낼 필요가 없습니다. 이로써 변경을 리뷰받기 위해 보내는 데 드는 장벽이 낮아집니다.

리뷰 측면에서 보면 GitHub 풀 리퀘스트는 리뷰하기가 훨씬 쉽습니다. 문법이 강조 표시된 깔끔한 diff를 제공하며, 이 diff는 통합(unified) 보기와 나란히(side by side) 보기 중 어느 쪽으로도 볼 수 있습니다. diff의 문맥을 파일 전체까지 펼쳐 볼 수 있습니다. 마지막으로 인라인 댓글과 풀 리퀘스트 전체에 대한 댓글을 달 수 있으며, 이를 보기 좋게 통합된 방식으로 보여 주고 더 이상 해당하지 않는 댓글은 숨겨 줍니다. GitHub는 또한 “렌더링된 diff” 보기를 제공하여, 원시 마크업의 diff를 리뷰할 필요 없이 (rst 같은) 렌더링된 마크업의 diff를 쉽게 볼 수 있게 해 줍니다.

풀 리퀘스트 작업 흐름을 사용하면 변경 사항을 실제로 병합하기 전에 미리 테스트하는 기능도 아주 쉽게 활성화할 수 있습니다. 각 풀 리퀘스트에는 여러 종류의 “커밋 상태”를 개수 제한 없이 적용할 수 있으며, 이를 통해 커밋(따라서 풀 리퀘스트)을 대기 중, 성공, 오류, 실패 상태 중 하나로 표시합니다. 이를 통해 풀 리퀘스트가 모든 테스트를 통과하는지, 기여자가 CLA에 서명했는지 등을 인라인으로 쉽게 확인할 수 있습니다.

GitHub 풀 리퀘스트를 실제로 병합하는 일은 매우 간단합니다. 풀 리퀘스트의 모든 검사 상태가 성공을 뜻하는 초록색이 되면 코어 리뷰어가 “Merge” 버튼을 누르기만 하면 됩니다.

GitHub는 또한 웹 인터페이스만으로 프로젝트에 풀 리퀘스트를 제출할 수 있는 좋은 워크플로를 갖추고 있습니다. 이를 활용하면 Python 문서의 모든 페이지에 “Edit on GitHub” 버튼을 둘 수 있습니다. 오타나 부정확한 내용을 발견했거나 지금 작성 중인 문서를 개선하고 싶은 사람은 그 버튼을 누르기만 하면 브라우저 내 편집기가 열리므로, 브라우저를 벗어나지 않고 편안하게 변경 사항을 만들고 풀 리퀘스트를 제출할 수 있습니다.

Phabricator

이 PEP는 GitHub 풀 리퀘스트와 더불어 Phabricator 인스턴스를 구축하고 이를 GitHub에 호스팅된 저장소에 연결할 것도 제안합니다. 이렇게 하면 Phabricator의 리뷰 애플리케이션인 Differential과 Audit을 활용할 수 있습니다.

Differential은 GitHub 풀 리퀘스트와 비슷한 함수(기능)를 수행하지만, Phabricator에 패치를 업로드하려면 arc 명령줄 도구를 설치해야 한다는 점이 다릅니다.

특정 저장소에 Phabricator를 활성화할지는 저장소별로 선택할 수 있습니다. 이 PEP는 CPython 저장소에서는 반드시 활성화해야 한다고만 제안하며, PEP 저장소처럼 규모가 작은 저장소에서는 그만한 노력을 들일 가치가 없을 수도 있습니다.

비판

X는 Python으로 작성되어 있지 않습니다

현재 도구(Mercurial, Rietveld)가 가진 특징 중 하나는 모든 구성 요소가 주로 Python으로 작성되어 있다는 점입니다. 이 PEP는 우리가 어쩌다 Python으로 작성된 도구 중 최고인 도구가 아니라, 해당 작업에 최고인 도구에 집중해야 한다고 믿습니다. 자원봉사자의 시간은 모든 오픈 소스 프로젝트에 소중한 자원이며, 도구 작성자가 어떤 언어를 사용했는지보다 도구 자체의 장단점에 집중할 때 그 시간을 가장 잘 존중하고 활용할 수 있습니다.

한 가지 우려는 도구를 우리에게 맞게 수정할 수 있느냐는 점입니다. 그러나 여기서의 목표 중 하나는 소프트웨어를 우리에게 맞게 수정하지 않고, 대신 우리 자신을 더 표준적인 워크플로에 맞추는 것입니다. 이러한 표준화는 도구를 별도 수정 없이 그대로 재사용할 수 있게 해 주므로, 개발자가 실제로 Python 자체에 몰두할 시간을 확보할 수 있을 뿐 아니라 프로젝트 간 지식 공유도 가능해진다는 이점이 있습니다.

그렇지만 도구를 수정해야 하는 경우에도, Git 자체는 CPython과 마찬가지로 대부분 C로 작성되어 있습니다. 또한 Python을 포함한 어떤 언어로든 Git용 명령을 작성할 수 있습니다. Phabricator는 웹 분야에서 꽤 널리 쓰이고 비교적 배우기 쉬운 언어인 PHP로 작성되어 있습니다. GitHub 자체는 대부분 Ruby로 작성되어 있지만, 오픈 소스가 아니어서 수정할 수 없으므로 구현 언어는 전혀 의미가 없습니다.

GitHub는 자유/오픈 소스가 아닙니다

GitHub는 이 제안에서 큰 부분을 차지하므로, 실용성보다 이념을 중시하는 사람은 그 이유만으로 이 PEP에 반대할 수도 있습니다. 이 PEP는 전적으로 자유/오픈 소스 소프트웨어만 사용하는 것이 매력적인 발상이자 고귀한 목표이기는 하지만, 무언가가 자유/오픈 소스인지를 절대적인 요건으로 취급하는 것보다는 잘 유지 관리되고, 기여자가 이미 알고 있거나 배워 두면 다른 프로젝트에도 적용할 수 있는 좋은 도구를 제공하여 기여자의 시간을 소중히 여기는 것이 더 중요한 고려 사항이라고 믿습니다.

그러나 역사는 선의를 가진 독점 기업도 때로는 더 이상 선의를 유지하지 않을 수 있음을 보여 주었습니다. 이에 대해서는 몇 가지 방법으로 대비하고 있습니다.

우리는 GitHub 이슈 트래커를 사용하지 않습니다. CPython에 쓰기에는 기능이 충분하지 않기 때문이기도 하고, 주 CPython 저장소의 경우 언젠가 GitHub를 떠나야 할 때 이슈를 다른 곳으로 옮길 수 있느냐가 GitHub가 계속 API 접근을 허용하는지에 달려 있기 때문이기도 합니다.
우리는 GitHub 풀 리퀘스트 워크플로를 사용하지만, 그 모든 변경 사항은 Git 안에 존재합니다. 따라서 GitHub 저장소의 미러에 그 모든 풀 리퀘스트를 쉽게 담을 수 있습니다. GitHub가 갑자기 “악해진다면” 댓글은 잃을 수도 있지만, 변경 사항 자체는 그대로 남아 있을 것입니다.
저희는 GitHub의 저장소 호스팅 기능을 활용하고 있지만, 이는 단지 git일 뿐이므로 GitHub를 떠나는 일은 저장소를 다른 위치로 푸시하는 것만큼 간단합니다. 저장소 자체의 데이터 이식성은 매우 높습니다.
또한 저희는 GitHub를 사용하고 싶지 않은 사람들에게 대안을 제공하기 위해 Phabricator도 활용하고 있습니다. 이는 언젠가 GitHub 사용을 중단해야 할 경우를 대비해 미리 마련된 대체 수단의 역할도 합니다.

GitHub에 의존하면 플랫폼 자체의 이점 외에도 여러 가지 이점이 따릅니다. GitHub는 상업적으로 지원되는 사업이므로 서비스 유지를 담당하는 상근 직원이 있습니다. 여기에는 서비스가 계속 가동되도록 하는 일, 다양한 보안 취약점에 대한 패치가 계속 적용되도록 하는 일, 그리고 시간이 지남에 따라 소프트웨어와 인프라를 더욱 개선하는 일이 포함됩니다.

Mercurial이 Git보다 낫다는 주장

기술적인 수준에서 Mercurial과 Git 중 어느 쪽이 더 나은지는 매우 주관적인 의견입니다. 이 PEP는 Git과 Mercurial 중 어느 쪽의 메커니즘이 더 나은지 언급하지 않으며, 대신 각 선택지에서 얻을 수 있는 네트워크 효과에 초점을 맞춥니다. 이 PEP는 Git으로의 전환을 제안하므로 Mercurial을 선호하는 사람들은 배제되지만, 그러한 사용자들은 서버 측이 Git인 저장소에서 작업할 수 있게 해 주는 Mercurial용 hg-git [2] 확장을 사용하여 Mercurial로 계속 쉽게 작업할 수 있습니다.

CPython 워크플로가 너무 복잡하다는 주장

이전 논의에서 나온 의견 중 하나는 CPython의 다중 브랜치 모델이 GitHub 풀 리퀘스트에는 너무 복잡하다는 것이었습니다. 이 PEP는 그 주장이 정확하지 않다고 봅니다.

현재 어떤 변경이든 2.7과 3.x용 패치를 수동으로 만들어야 하며, 이 점은 전혀 달라지지 않습니다.

누군가 현재 안정 브랜치(현재는 3.4)에 대한 수정 사항을 제출하면, GitHub 풀 리퀘스트 워크플로를 사용하여 현재 안정 브랜치를 master 브랜치로 병합하는 풀 리퀘스트를 브라우저에서 만들 수 있습니다(병합 충돌이 없다고 가정할 때). 병합 충돌이 있다면 로컬에서 처리해야 합니다. 이는 병합이 항상 로컬에서 이루어져야 하는 현재 상황보다 개선된 것입니다.

마지막으로, 누군가 현재 개발 브랜치에 대한 수정 사항을 제출했을 때 이를 안정 브랜치에도 포함하고자 한다면, 현재는 이를 안정 브랜치에 수동으로 적용해야 합니다. 새 워크플로에서도 이 작업은 마찬가지로 로컬에서 이루어져야 하지만, 사소한 변경이라면 GitHub 웹 편집기에서 쉽게 처리할 수 있습니다.

이를 살펴보면, 저는 어떤 시스템도 오래 유지되는 여러 브랜치를 관리하는 데 따르는 복잡성을 감출 수 있다고 생각하지 않습니다. 도구가 할 수 있는 유일한 일은 변경 사항을 최대한 쉽게 제출할 수 있도록 하는 것입니다.

예시: Scientific Python

git과 GitHub로의 이전에 깔린 핵심 아이디어 중 하나는, DVCS와 저장소 호스팅, 그리고 사용하는 워크플로의 한 가지 특성이 해당 도구를 사용하는 커뮤니티의 소셜 네트워크와 규모라는 것입니다. Python 커뮤니티의 하위 커뮤니티인 Scientific Python 커뮤니티의 사례를 보면 이것이 사실임을 알 수 있습니다. 이들은 이미 SciPy 스택의 핵심 구성 요소 대부분을 풀 리퀘스트 기반 워크플로를 사용하여 GitHub로 이전했습니다. 이 과정은 IPython에서 시작되었으며, 더 많은 프로젝트가 옮겨 감에 따라 커뮤니티의 새 프로젝트에서도 자연스러운 기본값이 되었습니다.

그들은 이 이전으로 큰 이점을 얻었다고 말합니다. 가끔 기여하는 기여자들이 프로젝트마다 특수하게 맞춤화된 워크플로와 서로 다른 도구 모음을 익힐 필요 없이, 자신이 속한 하위 커뮤니티 안의 여러 프로젝트를 쉽게 오갈 수 있게 되었다는 것입니다. 이들은 사람들이 서로 다른 도구와 워크플로를 배우는 대신 한정된 시간을 실제 기여에 쓸 수 있게 되면, 한 프로젝트에 더 많이 기여할 뿐만 아니라 다른 프로젝트로까지 영역을 넓혀 기여한다는 사실을 발견했습니다. 이 이전은 또한 해당 커뮤니티 구성원들이 자신의 연구 자료와 교육 자료까지 GitHub에 공개하는 경향이 늘어난 원인으로도 꼽힙니다.

이 사례는 널리 쓰이는 도구 모음과 워크플로로 옮겨 가는 것의 진정한 힘을 보여 줍니다. 차이가 하나 생길 때마다 새로운 기여자와 가끔 기여하는 기여자가 넘어야 할 장애물이 하나씩 늘어나고, 그 워크플로를 익히는 데 들인 시간을 다른 프로젝트에서 다시 활용하기도 어려워지기 때문입니다.

참고 문헌

Copyright

This document has been placed in the public domain.