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에 기여할 때마다 프로세스, 워크플로 및 도구를 기억하거나 다시 익혀야 하며, FLOSS 생태계의 다른 프로젝트에서 작업하면서 축적한 장기 기억과 익숙함을 활용할 수 있다는 이점을 누리지 못합니다. CPython에서 얻은 지식은 다른 프로젝트에 적용하기 어려울 가능성이 높습니다.
- 맞춤형 도구를 계속 유지 관리하고, 시간이 지남에 따라 개선하며, 버그를 수정하고, 보안 문제를 해결하고, 더 일반적으로는 전 세계적인 협업을 통한 온라인 소프트웨어 개발의 새로운 표준에 적응하려면 Python/PSF 인프라 팀의 부담이 훨씬 커집니다.
이러한 제약은 참여도가 높은 기여자(예: 핵심 Python 개발자)뿐만 아니라, 새로운 도구 및 워크플로 모음을 배우는 것보다 버그 수정 사항을 적용하는 데 더 관심이 있는 보다 가벼운 “drive-by” 기여자에게 특히 기여의 장벽으로 작용합니다.
이 PEP는 서로 다른 버전 제어 시스템과 현대적이며 잘 유지 관리되는 호스팅 솔루션을 모두 도입할 것을 제안함으로써 이러한 제약을 해결합니다. 이는 CPython 개발을 수년간 이어 갈 수 있는 현대적이고 널리 이해되는 프로세스를 구현하는 것을 목표로 합니다.
버전 제어 시스템
현재 CPython 및 지원 저장소는 Mercurial을 사용합니다. 현대적인 분산 버전 제어 시스템으로서 Mercurial은 Subversion에서 마이그레이션한 이후 지금까지 우리를 잘 지원해 왔습니다. 그러나 VCS를 평가할 때는 VCS 자체의 기능뿐만 아니라 해당 VCS를 둘러싼 커뮤니티의 네트워크 효과와 인지도도 고려해야 합니다.
실제로 여기에는 Mercurial과 Git이라는 두 가지 선택지만 있습니다. 두 시스템의 기술적 기능은 대체로 동등하므로, 이 PEP는 대신 두 시스템의 사회적 측면에 초점을 맞춥니다.
특정 VCS를 사용하는 프로젝트나 사람의 수를 정확히 파악하는 것은 불가능하지만, 여러 정보 출처를 살펴 어떤 VCS를 프로젝트에서 사용하는지 추론할 수는 있습니다.
The Open Hub(이전의 Ohloh) 통계 [1]은 The Open Hub가 색인한 저장소 중 37%가 Git을 사용한다는 것을 보여 줍니다(Subversion은 48%로 Git에 앞서며, 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을 채택하더라도 해당 VCS의 지지자들이 Mercurial을 사용하는 것이 금지되지는 않습니다! Mercurial 사용자는 Mercurial 프런트엔드를 사용하여 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 안에서 완전히 작업할 수 있습니다. 이를 통해 변경 사항을 검토받기 위한 진입 장벽이 낮아집니다.
머지 요청은 검토하기가 훨씬 쉽습니다. 예를 들어, 통합 보기나 나란히 보기 중 어느 쪽에서도 작동하는 보기 좋은 구문 강조 차이점을 제공합니다. 머지 요청 전체와 인라인으로 댓글을 작성할 수 있으며, 더 이상 적용되지 않는 댓글은 숨기면서 이를 보기 좋은 통합 방식으로 표시합니다. 댓글은 숨기거나 다시 표시할 수 있습니다.
소스 브랜치가 대상 브랜치에 충돌 없이 적용된다면 머지 요청을 실제로 병합하는 작업은 매우 간단합니다. 핵심 검토자는 “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와 연락을 주고받았으며, 상대방은 긍정적인 관심을 보였습니다. 호스팅 제안의 세부 사항은 논의해야 합니다.
- 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.