PEP 507 – CPython을 Git과 GitLab으로 이전하기
- Author:
- Barry Warsaw <barry at python.org>
- Status:
- Rejected
- Type:
- Process
- Created:
- 30-Sep-2015
- Post-History:
- Resolution:
- Core-Workflow message
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 CPython 및 관련 저장소의 저장소 호스팅을 Git으로 이전할 것을 제안합니다. 또한 머지 리퀘스트, 코드 리뷰, 코드 호스팅을 처리하는 주된 방법으로 호스팅된 GitLab 인스턴스를 도입할 것을 제안합니다. 취지는 PEP 481과 비슷하지만, GitHub 대신 오픈 소스 대안을 제안하며 Phabricator를 운영하자는 제안은 제외합니다. PEP 481과 마찬가지로, 이 PEP는 PEP 474와 PEP 462의 대안으로 제시됩니다.
근거
CPython은 자신의 시간을 기부하는 많은 자원봉사자에게 의존하는 오픈 소스 프로젝트입니다. 건강하고 활기찬 오픈 소스 프로젝트가 모두 그렇듯이, CPython은 기존 개발자를 유지하는 것뿐만 아니라 새로운 자원봉사자를 끌어들이는 데에도 의존합니다. 자원봉사자의 시간이 가장 부족한 자원이라는 점을 고려하면, 기여자의 효율성을 극대화하고 기여에 따르는 마찰을 줄이는 프로세스를 제공하는 것은 프로젝트의 장기적인 건전성에 매우 중요합니다.
현재 CPython 프로젝트의 도구 체인은 도구들을 독자적이고 고유한 방식으로 조합한 것입니다. 이는 두 가지 중대한 영향을 미칩니다:
- 툴체인의 고유한 특성 때문에 기여자는 CPython에 기여할 때마다 절차, 워크플로, 도구를 기억해 내거나 다시 익혀야 하며, FLOSS 생태계의 다른 프로젝트에서 작업하면서 쌓은 장기 메모리와 익숙함을 활용하는 이점을 누리지 못합니다. CPython 작업에서 얻은 지식은 다른 프로젝트에 적용할 수 있을 가능성이 낮습니다.
- 독자적인 도구를 계속 유지 보수하고, 시간이 지남에 따라 개선하고, 버그를 고치고, 보안 문제에 대응하며, 더 넓게는 전 세계적 협업이 이루어지는 온라인 소프트웨어 개발의 새로운 표준에 적응하기 위해 Python/PSF 인프라 팀이 지는 부담이 훨씬 큽니다.
이러한 한계는 참여도가 높은 기여자(예: Python 핵심 개발자)에게도, 특히 새로운 도구와 워크플로를 배우는 것보다 자신의 버그 수정을 반영하는 데 더 관심이 있는 가벼운 “지나가는(drive-by)” 기여자에게는 더욱, 기여의 장벽으로 작용합니다.
이 PEP는 다른 버전 관리 시스템과 현대적이고 잘 유지 보수되는 호스팅 솔루션을 함께 도입할 것을 제안함으로써 이러한 한계를 해결합니다. 이 PEP는 앞으로 오랫동안 CPython 개발을 이끌어 갈, 현대적이고 널리 이해되는 프로세스를 가능하게 하는 것을 목표로 합니다.
버전 관리 시스템
현재 CPython 및 관련 저장소는 Mercurial을 사용합니다. Mercurial은 현대적인 분산 버전 관리 시스템으로서 Subversion에서 이전한 이후 제 역할을 잘 해 왔습니다. 그러나 VCS를 평가할 때는 VCS 자체의 기능뿐만 아니라 해당 VCS를 둘러싼 커뮤니티의 네트워크 효과와 인지도도 고려해야 합니다.
실제로 선택할 수 있는 현실적인 대안은 Mercurial과 Git 두 가지뿐입니다. 두 시스템의 기술적 역량은 대체로 동등하므로, 이 PEP는 대신 두 시스템의 사회적 측면에 초점을 맞춥니다.
특정 VCS를 사용하는 프로젝트나 사람의 정확한 수를 얻을 수는 없지만, 프로젝트들이 어떤 VCS를 사용하는지에 대한 여러 정보 출처를 살펴봄으로써 이를 추론할 수 있습니다.
The Open Hub(이전 명칭 Ohloh) 통계 [1]에 따르면 The Open Hub가 색인한 저장소의 37%가 Git을 사용하며(48%인 Subversion에 이어 두 번째), 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에 관한 사용법 안내서를 작성하고, 질문에 답하고, 글을 쓰는 사람이 더 많다는 뜻이며, 그 덕분에 새로운 사용자가 배우고 사용하려는 도구에 관한 답과 정보를 더 쉽게 찾을 수 있습니다. Git의 인기를 고려하면 Git을 중심으로 작성된 보조 도구도 더 많을 수 있습니다. 이는 GUI 클라이언트, 도우미 스크립트, 저장소 호스팅 등 모든 영역에서 선택지를 넓혀 줍니다.
더 나아가, 제안된 백엔드 저장소 형식으로 Git을 채택한다고 해서 Mercurial을 선호하는 사람들이 Mercurial을 사용하지 못하게 되는 것은 아닙니다! Mercurial 사용자에게는 Mercurial 프런트엔드를 사용하여 Git 서버에 푸시하고 Git 서버에서 풀할 수 있게 해 주는 [2] 플러그인이 있습니다. 이 플러그인은 유지 관리가 잘 되고 기능이 매우 풍부하며, Mercurial 사용자들 사이에서 평판이 좋은 것으로 보입니다.
저장소 호스팅
CPython의 공식 저장소를 어디에서 어떻게 호스팅할지는 어느 정도 VCS 선택에 따라 결정됩니다. Git을 사용하면 여러 선택지가 있습니다. 실제로 저장소를 Git으로 호스팅하면 여러 무료, 오픈 소스, 독점 코드 호스팅 사이트 등 여러 곳에 브랜치를 미러링할 수 있습니다.
그렇더라도 CPython이 단일한 공식 저장소를 채택하는 것은 여전히 중요하며, 이 저장소에는 로컬 VCS 조작을 항상 요구하지 않고도 편리하고 일반적인 여러 상호 작용을 전적으로 웹을 통해 할 수 있게 해 주는 웹 프런트엔드가 있어야 합니다. 이러한 상호 작용에는 최소한 인라인 댓글을 사용한 코드 리뷰, 브랜치 간 차이 비교, CI 통합, 자동 병합이 포함됩니다.
이 PEP는 python.org 도메인 안에서 운영되고, PSF와 Python 인프라 팀이 접근할 수 있으며 최종 통제권을 가지지만, GitLab, Inc.가 기증하고 호스팅하며 주로 유지 관리하는 [3] 인스턴스를 채택할 것을 제안합니다.
왜 GitLab입니까? 현대적인 웹 상호 작용, 소프트웨어 워크플로, CI 통합을 갖춘 완전한 기능의 Git 호스팅 시스템이기 때문입니다. GitLab의 Community Edition(CE)은 오픈 소스 소프트웨어이므로 CPython 커뮤니티의 원칙과 밀접하게 부합합니다.
코드 리뷰
현재 CPython은 Google App Engine 없이 실행되도록 수정한 Rietveld의 커스텀 포크를 사용하고 있으며, 이 포크는 현재 사실상 한 사람만이 유지 관리하고 있습니다. 이 포크에는 여러 현대적인 코드 리뷰 도구에 있는 일반적인 기능이 빠져 있습니다.
이 PEP는 제안된 모든 변경 사항의 리뷰를 원활하게 하기 위해 GitLab에 내장된 병합 요청과 온라인 코드 리뷰 기능을 활용할 것을 제안합니다.
GitLab 병합 요청
GitLab에서 호스팅하는 프로젝트의 일반적인 워크플로는 기능 브랜치나 버그 수정 브랜치를 대상 브랜치에 병합해 달라고 요청하는 병합 요청을 제출하는 것이며, 대상 브랜치는 보통 하나 이상의 안정 유지 보수 브랜치이거나 새 기능의 경우 다음 버전의 master 브랜치입니다. GitLab의 머지 리퀘스트는 형태와 함수 면에서 GitHub의 풀 리퀘스트와 비슷하므로, 이미 후자에 익숙한 사람이라면 누구나 전자를 곧바로 활용할 수 있을 것입니다.
제출하고 나면 제출자와 리뷰어가 변경 사항에 관해 대화를 나눌 수 있습니다. 여기에는 일반 댓글뿐 아니라, 소스 브랜치와 대상 브랜치 간 차이의 특정 줄에 첨부되는 인라인 댓글도 포함됩니다. 또한 제출된 브랜치에 대해 지속적 통합을 자동으로 실행하도록 프로젝트를 구성할 수 있으며, 그 결과는 병합 요청 페이지에서 바로 확인할 수 있습니다. 따라서 리뷰어와 제출자 모두 테스트 결과를 즉시 볼 수 있으므로, 테스트를 통과한 브랜치만 병합하기가 훨씬 쉬워집니다. 소스 브랜치에 새로 푸시할 때마다(예: 댓글 작성자의 피드백에 대응하거나 실패한 테스트를 고치기 위해) CI가 새로 실행되므로, 요청의 상태는 항상 최신 커밋을 반영합니다.
병합 요청은 예전의 “버그 트래커에 패치를 제출하는” 모델에 비해 상당히 큰 장점이 있습니다. 병합 요청을 사용하면 개발자는 패치 파일을 만들거나 패치를 올릴 올바른 위치를 알아낼 필요 없이, 표준 VCS 도구를 사용해 완전히 VCS 안에서 작업할 수 있습니다. 이로써 변경 사항을 리뷰받기 위해 보내는 일의 문턱이 낮아집니다.
병합 요청은 리뷰하기가 훨씬 쉽습니다. 예를 들어 머지 리퀘스트는 문법 강조가 적용된 보기 좋은 diff를 제공하며, 이 diff는 통합 보기나 나란히 보기 중 어느 방식으로도 볼 수 있습니다. 병합 요청에서는 인라인으로도, 병합 요청 전체에 대해서도 코멘트를 달 수 있으며, 이를 보기 좋게 하나로 통합해 보여 주고 더 이상 해당되지 않는 코멘트는 숨겨 줍니다. 코멘트는 숨기거나 다시 표시할 수 있습니다.
소스 브랜치가 대상 브랜치에 깔끔하게 적용된다면, 병합 요청을 실제로 병합하는 일은 매우 간단합니다. 핵심 리뷰어는 “Merge” 버튼을 누르기만 하면 되며, 그러면 GitLab이 자동으로 병합을 수행합니다. 소스 브랜치는 선택적으로 리베이스할 수 있으며, 병합이 완료되면 소스 브랜치를 자동으로 삭제할 수 있습니다.
GitLab에는 웹 인터페이스만으로 프로젝트에 풀 리퀘스트를 제출할 수 있는 좋은 워크플로도 있습니다. 이를 통해 Python 문서의 모든 페이지에 “Edit on GitLab” 버튼을 둘 수 있으며, 오타나 부정확한 내용 같은 것을 발견한 사람이나 지금 읽고 있는 문서를 그저 개선하고 싶은 사람이 이를 활용할 수 있습니다. 이들은 그 버튼을 누르기만 하면 브라우저 내 편집기가 열리고, 브라우저에서 편하게 변경 사항을 만들고 병합 요청까지 제출할 수 있습니다.
비판
X가 Python으로 작성되어 있지 않음
현재 도구(Mercurial, Rietveld)가 가진 한 가지 특징은 모든 구성 요소의 주 언어가 Python이라는 점입니다. 이 PEP는 반드시 Python으로 작성된 도구 중 최선의 도구가 아니라, 해당 작업에 최선인 도구에 더 초점을 맞춥니다. 자원봉사자의 시간은 모든 오픈 소스 프로젝트에서 가장 소중한 자원이며, 도구 작성자가 어떤 언어를 사용했는지보다 도구 자체의 장단점에 집중할 때 그 시간을 가장 잘 존중하고 활용할 수 있습니다.
한 가지 우려는 우리에게 맞게 도구를 수정할 수 있는지 여부이지만, 여기서의 목표 중 하나는 우리에게 맞게 소프트웨어를 수정하지 않고, 대신 우리 스스로를 더 표준화된 워크플로에 맞추는 것입니다. 이러한 표준화는 도구를 별도 수정 없이 바로 재사용할 수 있게 하여 개발자가 실제로 Python 자체를 작업하는 데 시간을 쓸 수 있게 해 줄 뿐 아니라, 프로젝트 간 지식 공유도 가능하게 한다는 점에서 효과를 발휘합니다.
그러나 도구를 수정해야 하는 경우라도, Git 자체는 CPython과 마찬가지로 대부분 C로 작성되어 있습니다. 또한 Python을 포함한 어떤 언어로든 Git용 명령을 작성할 수 있습니다. GitLab 자체는 대부분 Ruby로 작성되어 있으며, 오픈 소스 소프트웨어이므로 대부분의 Python 프로그래머에게 익숙하지 않을 수 있는 언어이긴 하지만 업스트림 Community Edition에 병합 요청을 제출할 수 있습니다.
Mercurial이 Git보다 낫다는 의견
기술적인 수준에서 Mercurial과 Git 중 어느 쪽이 더 나은지는 매우 주관적인 의견입니다. 이 PEP는 Git과 Mercurial 중 어느 쪽의 작동 방식이 더 나은지를 밝히지 않으며, 대신 각 선택지에서 얻을 수 있는 네트워크 효과에 초점을 맞춥니다. 이 PEP는 Git으로의 전환을 제안하지만, Mercurial 사용자가 완전히 소외되는 것은 아닙니다. Mercurial용 hg-git 확장을 사용하면 서버 측 Git 저장소를 다루는 일이 상당히 쉽고 간단합니다.
CPython 워크플로가 너무 복잡함
이전 논의에서 나온 의견 중 하나는 CPython의 다중 브랜치 모델이 GitLab 방식의 병합 요청에는 너무 복잡하다는 것이었습니다. 이 PEP는 그 의견에 동의하지 않습니다.
현재 어떤 변경이든 2.7과 3.x용 패치를 각각 수동으로 만들어야 하며, 이 점은 전혀 달라지지 않습니다.
누군가 현재 안정 브랜치(예: 3.5)에 대한 수정 사항을 제출하면, 병합 충돌이 없다는 전제하에 병합 요청 워크플로를 사용하여 현재 안정 브랜치를 master 브랜치에 병합해 달라는 요청을 만들 수 있습니다. 언제나 그렇듯이 병합 충돌은 로컬에서 수동으로 해결해야 합니다. 개발자에게는 병합을 로컬에서 수행할 선택권도 있으므로, 병합이 반드시 항상 로컬에서 이루어져야 하는 현재 상황보다 개선됩니다.
현재 개발 브랜치의 수정 사항을 안정 릴리스 브랜치에도 적용해야 하는 경우, 많은 상황에서 해당 변경 사항을 로컬에서 체리 픽하여 다른 브랜치에 적용하고 각 안정 브랜치마다 병합 요청을 제출할 수 있습니다. 단순히 체리 픽한 후 로컬에서 병합을 완료하는 것도 가능합니다. 이 모든 작업은 표준 Git 명령과 기법으로 수행되며, 안정 브랜치로 병합하는 경우에도 이러한 모든 변경 사항이 리뷰 및 CI 테스트 워크플로를 거칠 수 있다는 장점이 있습니다. 사소한 변경 사항은 GitLab 웹 편집기에서 쉽게 처리할 수 있습니다.
어떤 시스템도 수명이 긴 여러 브랜치를 유지 관리하는 데 따르는 복잡성을 모두 감출 수는 없습니다. 도구가 할 수 있는 일은 변경 사항을 제출하고 커밋하는 작업을 가능한 한 쉽게 만드는 것뿐입니다.
미해결 문제
- GitLab은 어느 수준의 호스팅 지원을 제공합니까? PEP 작성자는 GitLab CEO와 연락을 주고받았으며, GitLab 측에서도 긍정적인 관심을 보였습니다. 호스팅 제안의 세부 사항은 논의가 필요합니다.
- Roundup은 어떻게 되며, GitLab 이슈 트래커로 전환합니까? 현재 이 PEP는 Roundup에서 GitLab 이슈로 옮기자고 제안하는 것이 아닙니다. 지금은 Roundup에 투자한 것이 너무 많으며, 데이터를 이전하는 것은 엄청난 작업이 될 것입니다. GitLab은 웹훅을 지원하므로, 아마도 웹훅을 사용하여 병합 및 기타 이벤트를 Roundup 업데이트와 통합하려 할 것입니다(예: 현재 하는 것처럼 커밋에 대한 포인터 포함, 이슈 닫기 등).
- wiki.python.org는 어떻게 됩니까? 아무 변화도 없습니다! GitLab이 저장소 내 위키를 지원하기는 하지만, 우리의 Moin 위키를 이전할 이유는 없습니다.
- 기존 GitHub 미러는 어떻게 됩니까? 공식 업스트림 브랜치가 Git에서 네이티브로 호스팅되면 아마도 미러를 다시 생성하려 할 것입니다. 이로 인해 커밋 ID가 바뀔 수 있지만, 그 이후에는 공식 Git 브랜치와 저장소를 널리 미러링하기가 쉬워질 것입니다.
- GitLab 인스턴스는 어디에 위치합니까? 물리적으로는 GitLab이 선택하는 호스팅 제공업체에 위치합니다. gitlab.python.org(또는 git.python.org?)가 이 호스트를 가리키도록 할 것입니다.
참고 문헌
Copyright
This document has been placed in the public domain.