PEP 481 – Git, Github 및 Phabricator로 CPython 마이그레이션

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를 찾고 계시다면, 관련 PEP 512를 참조하십시오.

이 PEP는 CPython 및 지원 저장소의 저장소 호스팅을 Git과 Github로 이전할 것을 제안합니다. 또한 변경 사항 검토를 처리하기 위해 Github Pull Requests의 대안으로 Phabricator를 추가할 것을 제안합니다. 이 PEP는 동일한 전반적 이점을 달성하려 하지만 Mercurial을 지원하고 완전히 오픈 소스인 도구로만 제한하는 PEP 474와 PEP 462의 대안으로 제시됩니다.

근거

CPython은 여러 자원봉사자가 자신의 시간을 기부하는 데 의존하는 오픈 소스 프로젝트입니다. 오픈 소스 프로젝트인 CPython은 계속해서 충분한 인력을 확보하기 위해 새로운 자원봉사자를 끌어들이는 동시에 기존 자원봉사자를 유지하는 데 의존합니다. 프로젝트에 투입할 수 있는 인력의 규모를 늘리는 것뿐만 아니라, 실제로 이용 가능한 인력을 효과적으로 활용할 수 있도록 해야 합니다.

현재 CPython 프로젝트의 도구 체인은 맞춤형이며 독특한 도구 조합으로, 많은 오래된 프로젝트에서 볼 수 있는 것과 유사한 작업 흐름을 강제하지만 시간이 지날수록 이러한 흐름의 인기는 점점 줄어들고 있습니다.

CPython 도구 체인과 작업 흐름의 일회성 특성으로 인해 새로운 기여자는 CPython에 기여하기 시작하기 전에 도구와 작업 흐름을 익히는 데 시간을 들여야 합니다. 새로운 기여자가 CPython의 작업 흐름을 익히는 과정을 거치더라도, 그 지식을 자신이 향후 기여하고자 하는 프로젝트에 적용할 수 있을 가능성은 낮습니다. 이는 기여를 가로막는 장벽으로 작용하여 잠재적인 새로운 기여자를 단념하게 합니다.

또한 CPython이 사용하는 도구는 유지 관리가 부족하고 낡았으며, 커미터가 변경 사항을 검토하고 승인할 때 자신의 시간을 더욱 효과적으로 사용할 수 있도록 하는 중요한 기능이 부족합니다. 유지 관리가 부족하다는 사실은 버그가 수정되더라도 더 오래 남아 있을 가능성이 높고, 장기간 중단될 가능성도 더 높다는 것을 의미합니다. 낡았다는 사실은 현대 웹 플랫폼의 기능을 효과적으로 활용하지 못한다는 것을 의미합니다. 마지막으로 커밋 사전 테스트 기능과 자동 병합 도구가 없는 등 여러 중요한 기능이 부족하므로, 커미터는 가장 간단한 변경 사항을 커밋할 때조차 불필요한 잡무를 수행해야 합니다.

버전 관리 시스템

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

실제로 선택지는 Mercurial과 Git, 두 가지뿐입니다. 두 시스템의 기술적 기능은 대체로 동등합니다. 이러한 이유로 이 PEP는 VCS 시스템에 관한 기술적 논거는 대체로 배제하고 사회적 측면에 대신 초점을 맞춥니다.

특정 VCS를 사용하는 프로젝트나 사람의 수를 정확히 파악하는 것은 불가능하지만, 여러 정보 출처에서 프로젝트가 어떤 VCS를 사용하는지 살펴보면 이를 추론할 수 있습니다.

Open Hub(이전의 Ohloh) 통계 [1]는 The Open Hub에서 색인된 저장소 중 37%가 Git을 사용한다는 것을 보여 줍니다(SVN의 48%에 이어 두 번째이며, Mercurial은 2%에 불과하고 1%인 bazaar만을 앞섭니다). 이는 The Open Hub에서 Git이 Mercurial보다 18배를 조금 넘는 인기를 누리고 있음을 의미합니다.

PyPI 자체도 서로 다른 VCS의 인기도에 관한 또 다른 정보 출처입니다. 이 출처는 Python용으로 개발된 프로젝트를 나타내므로 Python 커뮤니티 자체를 더 직접적으로 대상으로 합니다. 안타깝게도 PyPI에는 이 정보를 나타내기 위한 표준 위치가 없으므로 수동 처리가 필요합니다. 검색 범위를 PyPI의 상위 100개 프로젝트(다운로드 수순)로 제한하면, 그중 62%가 Git을 사용하고 22%가 Mercurial을 사용하며 13%는 다른 것을 사용한다는 사실을 확인할 수 있습니다. 이로써 PyPI의 상위 100개 프로젝트에서는 Git의 인기가 Mercurial보다 거의 3배에 달합니다.

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

새로운 기여자의 경우, 다른 프로젝트 작업의 일부로 이미 Git의 기초를 배웠거나 이제 막 Git을 배우는 중이라면 그 지식을 다른 프로젝트에 적용할 수 있을 가능성이 높아집니다. 또한 더 큰 커뮤니티는 Git에 관한 사용법 안내서를 작성하고, 질문에 답하며, 글을 작성하는 사람이 더 많다는 의미이므로, 새로운 사용자가 배우려는 도구에 대한 답변과 정보를 더 쉽게 찾을 수 있습니다.

또 다른 이점은 커뮤니티 규모가 더 크다는 특성상, 이를 중심으로 작성되는 도구도 더 많아진다는 점입니다. 이로써 GUI 클라이언트, 도우미 스크립트, 저장소 호스팅 등을 비롯한 모든 분야에서 선택지가 늘어납니다.

저장소 호스팅

이 PEP는 GitHub Pull Request 제출을 허용할 것을 제안하지만, GitHub에는 GitHub에서 호스팅되지 않는 저장소를 대상으로 Pull Request를 제출할 방법이 없습니다. 이 PEP는 또한 GitHub Pull Request뿐 아니라 Phabricator의 Differential 앱을 사용하여 제안된 변경 사항을 제출할 수 있도록 할 것을 제안하며, Phabricator 실제로 Phabricator에서 호스팅되지 않는 저장소를 대상으로 변경 사항을 제출할 수 있도록 허용합니다.

이러한 이유로 이 PEP는 저장소의 표준 위치로 GitHub를 사용하고 Phabricator에 읽기 전용 미러를 두도록 제안합니다. 향후 어느 시점에 GitHub가 더 이상 필요하지 않게 되면 저장소 호스팅을 Phabricator만으로 쉽게 옮기고 GitHub Pull Request를 수락하는 기능을 제거할 수 있습니다.

GitHub에서 저장소를 호스팅하는 것과 더불어 모든 저장소의 읽기 전용 사본도 PSF Infrastructure에 미러링됩니다.

코드 리뷰

현재 CPython은 Google App Engine에서 실행되지 않도록 수정된 Rietveld의 사용자 지정 포크를 사용하고 있는데, 이는 현재 실제로 한 사람만 유지 관리할 수 있습니다. 또한 많은 최신 코드 리뷰 도구에 있는 기능도 제공하지 못합니다.

이 PEP는 GitHub Pull Request와 Phabricator 변경 사항 모두를 사용하여 변경 사항을 제안하고 코드를 리뷰할 수 있도록 할 것을 제안합니다. 이는 기여자가 변경 사항을 제출하는 데 가장 적합한 도구를 선택할 수 있게 하고, 리뷰어가 자신이 가장 선호하는 도구에서 변경 사항을 검토하는 데 집중할 수 있도록 두 가지 방식을 모두 제안합니다.

GitHub Pull Request

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

GitHub Pull Request는 이전의 “버그 추적기에 패치를 제출하는” 모델에 비해 상당히 큰 장점이 있습니다. 이를 통해 개발자는 표준 VCS 도구를 사용하여 VCS 내에서 완전히 작업할 수 있으므로 패치 파일을 만들고 이를 업로드할 올바른 위치가 어디인지 알아낼 필요가 없습니다. 이로써 변경 사항을 리뷰받기 위한 장벽이 낮아집니다.

리뷰 측면에서 GitHub Pull Request는 훨씬 쉽게 리뷰할 수 있으며, 통합 보기나 나란히 보기 중 하나로 표시할 수 있는 보기 좋은 구문 강조 diff를 제공합니다. diff의 컨텍스트를 전체 파일까지 포함하여 확장할 수 있습니다. 마지막으로 인라인으로, 그리고 Pull Request 전체에 대해 주석을 달 수 있으며, 더 이상 적용되지 않는 주석도 숨겨 주는 보기 좋은 통합 방식으로 이를 표시합니다. GitHub는 또한 원시 마크업의 diff를 리뷰할 필요 없이 렌더링된 마크업(예: rst)의 diff를 쉽게 볼 수 있는 “rendered 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로 작성되었으며, PHP는 웹 분야에서 상당히 일반적인 언어이고 비교적 쉽게 익힐 수 있습니다. GitHub 자체는 대부분 Ruby로 작성되었지만, 오픈 소스가 아니므로 수정할 방법이 없고 구현 언어는 완전히 무의미합니다.

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

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

그러나 역사는 때때로 자비로운 독점 기업도 더 이상 자비롭지 않게 될 수 있음을 보여주었습니다. 이에 대비하는 방법은 몇 가지가 있습니다.

GitHub Issue Tracker는 CPython에 충분히 강력하지 않기 때문에 사용하지 않으며, 또한 주 CPython 저장소의 경우 GitHub를 떠나야 할 때 문제를 다른 곳으로 가져갈 수 있는 능력이 GitHub가 계속 API 접근을 허용하는 데 의존하기 때문이기도 합니다.
GitHub 풀 리퀘스트 워크플로는 사용하지만, 그러한 변경 사항은 모두 Git 내부에 존재합니다. 따라서 GitHub 저장소의 미러에는 그러한 풀 리퀘스트가 모두 쉽게 포함될 수 있습니다. GitHub가 갑자기 “악의적”으로 변하면 댓글을 잃을 가능성은 있지만, 변경 사항 자체는 여전히 존재합니다.
저희는 GitHub의 저장소 호스팅 기능을 이용하고 있지만, 이는 단순히 git일 뿐이므로 GitHub에서 다른 곳으로 옮기는 것은 저장소를 다른 위치로 푸시하는 것만큼이나 간단합니다. 저장소 자체의 데이터 이식성은 매우 높습니다.
저희는 또한 GitHub 사용을 원하지 않는 사람들을 위한 대안을 제공하고자 Phabricator도 이용하고 있습니다. 이는 또한 언젠가 GitHub 사용을 중단해야 할 경우를 대비해 이미 마련되어 있을 대체 옵션으로도 작용합니다.

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

Mercurial이 Git보다 낫다는 주장

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

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

이전 논의에서 나온 한 가지 의견은 CPython의 다중 브랜치 모델이 GitHub Pull Request에 사용하기에는 너무 복잡하다는 것이었습니다. 이 PEP의 견해로는 그 주장은 사실이 아닙니다.

현재로서는 어떤 특정 변경이든 2.7과 3.x용 패치를 수동으로 만들어야 하며, 이 점은 이번 전환으로도 전혀 바뀌지 않습니다.

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

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

이를 살펴보면, 오래도록 유지되는 여러 브랜치를 관리하는 데 수반되는 복잡성을 감춰줄 수 있는 시스템은 어떤 것도 없다고 생각합니다. 도구가 할 수 있는 유일한 일은 변경 사항 제출을 가능한 한 쉽게 만드는 것뿐입니다.

예시: Scientific Python

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

그들은 이러한 전환으로 큰 이점을 얻었다고 주장하는데, 그것은 캐주얼 기여자들이 프로젝트마다 특별하고 별도로 맞춤화된 워크플로와 서로 다른 툴체인을 배울 필요 없이 자신의 하위 커뮤니티 내 여러 프로젝트 사이를 손쉽게 오갈 수 있게 해준다는 점입니다. 그들은 사람들이 서로 다른 도구와 워크플로를 배우는 데 시간을 쓰는 대신 실제 기여에 자신의 한정된 시간을 쓸 수 있게 되면, 한 프로젝트에 더 많이 기여할 뿐만 아니라 다른 프로젝트로도 영역을 넓혀 기여하게 된다는 사실을 발견했습니다. 이러한 전환은 또한 그 커뮤니티 구성원들이 자신의 연구 및 교육 자료를 GitHub에 게시하기까지 하는 경향이 늘어난 것과도 관련이 있다고 여겨집니다.

이 사례는 매우 인기 있는 툴체인과 워크플로로 옮겨가는 것의 진정한 힘을 보여주는데, 이는 각각의 차이가 신규 및 캐주얼 기여자들이 넘어야 할 또 다른 장애물을 만들어내며, 그 워크플로를 익히는 데 들인 시간을 다른 프로젝트에서 재사용하기 어렵게 만들기 때문입니다.

참고 자료

Copyright

This document has been placed in the public domain.