[Rejected] PEP 507 - Migrate CPython to Git and GitLab

원문 링크: PEP 507 - Migrate CPython to Git and GitLab

상태: Rejected 유형: Process 작성일: 30-Sep-2015

PEP 507 – CPython을 Git 및 GitLab으로 이전 제안

  • 작성자: Barry Warsaw
  • 상태: Rejected (거부됨)
  • 유형: Process (프로세스)
  • 생성일: 2015년 9월 30일
  • 해상도: Core-Workflow message

개요 (Abstract)

이 PEP는 CPython 및 관련 저장소의 호스팅을 Git으로 마이그레이션(이전)하고, 호스팅된 GitLab 인스턴스를 머지 리퀘스트(merge requests), 코드 리뷰(code reviews) 및 코드 호스팅을 처리하는 주요 방법으로 채택할 것을 제안합니다. 이 제안은 PEP 481과 유사하지만, GitHub에 대한 오픈 소스 대안을 제시하고 Phabricator 실행 제안을 제외합니다. 또한, PEP 474 및 PEP 462에 대한 대안으로 제공됩니다.

배경 (Rationale)

CPython은 수많은 자원봉사자들의 시간 기부에 의존하는 오픈 소스 프로젝트입니다. 건강하고 활발한 오픈 소스 프로젝트와 마찬가지로, 새로운 자원봉사자를 유치하고 기존 개발자를 유지하는 것이 중요합니다. 자원봉사자의 시간이 가장 희소한 자원이므로, 기여자의 효율성을 극대화하고 기여 과정의 마찰을 줄이는 프로세스를 제공하는 것은 프로젝트의 장기적인 건강에 매우 중요합니다.

현재 CPython 프로젝트의 도구 체인(tool chain)은 사용자 정의된 고유한 도구 조합입니다. 이는 두 가지 중요한 영향을 미칩니다.

  1. 진입 장벽: 도구 체인의 고유한 특성으로 인해, 기여자는 CPython에 기여할 때마다 프로세스, 워크플로우 및 도구를 기억하거나 다시 학습해야 합니다. 이는 다른 FLOSS(자유-오픈 소스 소프트웨어) 생태계 프로젝트에서 작업하면서 얻는 장기적인 기억력과 익숙함을 활용할 수 없게 만듭니다. 또한, CPython 작업에서 얻는 지식은 다른 프로젝트에 적용하기 어려울 수 있습니다.
  2. 유지보수 부담: Python/PSF 인프라 팀은 사용자 정의 도구를 지속적으로 유지보수하고, 시간이 지남에 따라 개선하며, 버그를 수정하고, 보안 문제를 해결하며, 전 세계적인 협업을 통한 온라인 소프트웨어 개발의 새로운 표준에 적응하기 위해 훨씬 더 큰 부담을 지게 됩니다.

이러한 제약 사항들은 적극적인 기여자(예: Python 핵심 개발자)뿐만 아니라, 새로운 도구 및 워크플로우를 학습하는 것보다 버그 수정을 완료하는 것에 더 관심을 갖는 “일회성(drive-by)” 기여자들에게도 기여의 장벽으로 작용합니다.

이 PEP는 다른 버전 관리 시스템(Version Control System)과 현대적이고 잘 유지보수되는 호스팅 솔루션을 채택함으로써 이러한 제약 사항들을 해결하고자 합니다. 이는 CPython 개발을 오랫동안 지속할 수 있는 현대적이고 잘 이해되는 프로세스를 가능하게 하는 것을 목표로 합니다.

제안 내용 (Proposal Details)

버전 관리 시스템 (Version Control System)

현재 CPython 및 지원 저장소는 Mercurial을 사용합니다. 현대적인 분산 버전 관리 시스템(DVCS)으로서 Subversion에서 마이그레이션한 이후 잘 작동했습니다. 그러나 VCS를 평가할 때는 VCS 자체의 기능뿐만 아니라 해당 VCS를 둘러싼 커뮤니티의 네트워크 효과와 점유율(mindshare)도 고려해야 합니다.

실질적으로 Mercurial과 Git 두 가지 옵션이 있습니다. 두 시스템의 기술적 기능은 대체로 동일하므로, 이 PEP는 사회적 측면에 중점을 둡니다.

  • 인기: The Open Hub(이전 Ohloh) 통계에 따르면, 인덱싱된 저장소의 37%가 Git을 사용하는 반면, Mercurial은 2%에 불과합니다. 이는 Git이 Mercurial보다 18배 이상 인기가 많다는 것을 보여줍니다. PyPI 상위 100개 프로젝트(다운로드 수 기준)를 분석한 결과, 62%가 Git을 사용하고 22%가 Mercurial을 사용하는 것으로 나타났습니다. 이는 Git이 오픈 소스 프로젝트에서 훨씬 더 인기 있는 DVCS라는 경험적 증거를 뒷받침합니다.
  • 이점: 더 인기 있는 VCS를 선택하면 다음과 같은 이점이 있습니다.
    • 새로운 기여자들은 Git의 기본 사항을 이미 학습했을 가능성이 높습니다.
    • 더 큰 커뮤니티는 Git에 대한 안내서, 질문 답변, 기사를 더 많이 제공하여 새로운 사용자가 정보를 쉽게 찾을 수 있도록 돕습니다.
    • 더 많은 보조 도구(GUI 클라이언트, 헬퍼 스크립트 등)가 Git을 중심으로 개발될 수 있습니다.
  • Mercurial 사용자를 위한 고려사항: Git을 백엔드 저장소 형식으로 채택해도 Mercurial 사용자의 사용을 금지하지 않습니다. Mercurial 사용자들은 hg-git 플러그인을 사용하여 Mercurial 프론트엔드를 통해 Git 서버에서 푸시(push) 및 풀(pull)을 할 수 있습니다.

저장소 호스팅 (Repository Hosting)

CPython의 공식 저장소가 어디서, 어떻게 호스팅되는지는 VCS 선택에 따라 결정됩니다. Git을 사용하면 여러 옵션이 있습니다. 저장소가 Git으로 호스팅되면, 브랜치는 다양한 무료, 오픈 소스 및 독점 코드 호스팅 사이트의 여러 위치에 미러링될 수 있습니다.

CPython이 단일 공식 저장소를 채택하는 것은 여전히 중요하며, 이 저장소는 로컬 VCS 조작 없이도 웹을 통해 편리하고 일반적인 상호작용(인라인 주석을 통한 코드 리뷰, 브랜치 비교, CI 통합, 자동 머지 등)을 가능하게 하는 웹 프론트엔드를 제공해야 합니다.

이 PEP는 python.org 도메인 내에서 실행되는 GitLab 인스턴스를 채택할 것을 제안합니다. 이 인스턴스는 PSF 및 Python 인프라 팀이 최종 제어권을 가지며 접근할 수 있지만, GitLab, Inc.에 의해 기부, 호스팅 및 주로 유지보수됩니다. GitLab은 현대적인 웹 상호작용, 소프트웨어 워크플로우 및 CI 통합을 지원하는 완벽한 기능을 갖춘 Git 호스팅 시스템이기 때문입니다. GitLab의 Community Edition(CE)은 오픈 소스 소프트웨어이며, 따라서 CPython 커뮤니티의 원칙과 밀접하게 일치합니다.

코드 리뷰 (Code Review)

현재 CPython은 Google App Engine에서 실행되지 않도록 수정된 Rietveld의 사용자 정의 포크를 사용하며, 현재 한 사람에 의해 주로 유지보수되고 있습니다. 이 시스템은 많은 최신 코드 리뷰 도구에 있는 일반적인 기능들이 누락되어 있습니다.

이 PEP는 모든 제안된 변경 사항의 리뷰를 용이하게 하기 위해 GitLab의 내장 머지 리퀘스트 및 온라인 코드 리뷰 기능을 활용할 것을 제안합니다.

GitLab 머지 리퀘스트 (GitLab merge requests)

GitLab 호스팅 프로젝트의 일반적인 워크플로우는 기능 또는 버그 수정 브랜치를 대상 브랜치(일반적으로 하나 이상의 안정적인 유지보수 브랜치 또는 새로운 기능을 위한 다음 버전 master 브랜치)에 머지하도록 요청하는 머지 리퀘스트를 제출하는 것입니다. GitLab의 머지 리퀘스트는 GitHub의 Pull Request와 형태와 기능이 유사하여, GitHub에 익숙한 사람이라면 즉시 사용할 수 있습니다.

  • 협업: 제출 후, 제출자와 리뷰어 사이에 변경 사항에 대한 대화가 가능합니다. 여기에는 일반적인 주석과 소스 및 대상 브랜치 간의 diff의 특정 줄에 첨부된 인라인 주석이 포함됩니다.
  • CI 통합: 프로젝트는 제출된 브랜치에서 지속적인 통합(CI)을 자동으로 실행하도록 구성할 수 있으며, 그 결과는 머지 리퀘스트 페이지에서 쉽게 볼 수 있습니다. 이는 리뷰어와 제출자 모두 테스트 결과를 즉시 확인할 수 있도록 하여, 통과하는 테스트가 있는 브랜치만 머지하는 것을 훨씬 쉽게 만듭니다.
  • 워크플로우 개선: 머지 리퀘스트는 이전의 “버그 트래커에 패치 제출” 모델에 비해 상당히 큰 이점을 가집니다. 개발자들이 패치 파일을 생성하거나 패치를 업로드할 올바른 위치를 찾을 필요 없이 표준 VCS 도구를 사용하여 완전히 VCS 내에서 작업할 수 있게 합니다. 이는 변경 사항을 리뷰를 위해 보내는 장벽을 낮춥니다.
  • 리뷰 용이성: 머지 리퀘스트는 리뷰하기가 훨씬 쉽습니다. 예를 들어, 통합 또는 나란히 보기(side-by-side views)로 작동할 수 있는 구문 강조(syntax highlighted) diff를 제공합니다. 인라인 주석 및 머지 리퀘스트 전체에 대한 주석을 허용하며, 더 이상 적용되지 않는 주석을 숨길 수 있는 멋진 통합된 방식으로 제시합니다.
  • 간단한 머지: 소스 브랜치가 대상 브랜치에 깔끔하게 적용되는 경우 머지 리퀘스트를 실제로 머지하는 것은 매우 간단합니다. 핵심 리뷰어는 GitLab이 자동으로 머지를 수행하도록 “Merge” 버튼을 누르기만 하면 됩니다.

GitLab은 웹 인터페이스를 통해서도 프로젝트에 Pull Request를 제출하는 좋은 워크플로우를 제공합니다. 이를 통해 Python 문서에 모든 페이지에 “Edit on GitLab” 버튼을 추가할 수 있으며, 오타, 부정확성 또는 단순히 문서 개선을 원하는 사람들이 이 버튼을 눌러 브라우저 내 에디터에서 변경 사항을 만들고 머지 리퀘스트를 제출할 수 있습니다.

비판에 대한 반박 (Criticism)

X는 Python으로 작성되지 않았다 (X is not written in Python)

현재 도구(Mercurial, Rietveld)의 한 가지 특징은 모든 구성 요소의 주요 언어가 Python으로 작성되었다는 것입니다. 이 PEP는 Python으로 작성된 최고의 도구가 아닌, 작업에 가장 적합한 도구에 중점을 둡니다. 자원봉사자의 시간은 모든 오픈 소스 프로젝트에서 가장 귀중한 자원이므로, 도구의 장점과 단점에 집중함으로써 그 시간을 가장 잘 존중하고 활용할 수 있습니다.

우려 중 하나는 도구를 우리에게 맞게 수정할 수 있는 능력입니다. 그러나 이 PEP의 목표 중 하나는 소프트웨어를 우리에게 맞게 수정하는 것이 아니라, 더 표준화된 워크플로우에 우리 자신을 적응시키는 것입니다. 이러한 표준화는 개발 시간을 절약하고 프로젝트 간 지식 공유를 가능하게 합니다.

Git 자체는 CPython과 마찬가지로 주로 C로 작성되었습니다. GitLab은 주로 Ruby로 작성되었지만, 오픈 소스 소프트웨어이므로 상위 Community Edition에 머지 리퀘스트를 제출할 수 있습니다.

Mercurial이 Git보다 낫다 (Mercurial is better than Git)

기술적 수준에서 Mercurial 또는 Git이 더 낫다는 것은 매우 주관적인 의견입니다. 이 PEP는 Git 또는 Mercurial의 메커니즘이 더 낫다고 주장하지 않으며, 대신 각 옵션에서 사용할 수 있는 네트워크 효과에 중점을 둡니다. 이 PEP는 Git으로 전환할 것을 제안하지만, Mercurial 사용자들은 완전히 소외되지 않습니다. Mercurial용 hg-git 확장 기능을 사용하면 서버 측 Git 저장소와 작업하는 것이 상당히 쉽고 간단합니다.

CPython 워크플로우가 너무 복잡하다 (CPython Workflow is too Complicated)

이전 논의에서 나온 의견 중 하나는 CPython의 다중 브랜치 모델이 GitLab 스타일 머지 리퀘스트에 비해 너무 복잡하다는 것이었습니다. 이 PEP는 이 의견에 동의하지 않습니다.

현재 특정 변경 사항은 2.7 및 3.x 브랜치에 대해 수동으로 패치를 생성해야 하며, 이 점은 변경되지 않습니다.

안정 브랜치(예: 3.5)에 대한 수정 사항이 제출되면, 머지 리퀘스트 워크플로우를 사용하여 병합 충돌이 없는 경우 현재 안정 브랜치를 master 브랜치로 병합하는 요청을 생성할 수 있습니다. 개발자들은 머지를 로컬에서 수행할 수도 있으므로, 이는 항상 로컬에서 머지가 이루어져야 하는 현재 상황보다 개선된 점을 제공합니다.

여러 개의 장기 실행 브랜치를 유지보수하는 데 관련된 모든 복잡성을 숨길 수 있는 시스템은 없습니다. 도구가 할 수 있는 유일한 일은 변경 사항을 제출하고 커밋하는 것을 가능한 한 쉽게 만드는 것입니다.

미해결 문제 (Open issues)

  • GitLab 호스팅 지원 수준: GitLab이 어느 정도의 호스팅 지원을 제공할지는 논의가 필요합니다.
  • Roundup 처리: 이 PEP는 현재 Roundup에서 GitLab 이슈 트래커로 이동할 것을 제안하지 않습니다. Roundup에 대한 투자가 너무 많고 데이터 마이그레이션이 엄청난 노력이기 때문입니다. GitLab의 웹훅(webhooks)을 사용하여 Roundup 업데이트와 머지 및 기타 이벤트를 통합할 수 있습니다.
  • wiki.python.org 처리: 현재 wiki.python.org는 변경되지 않습니다. GitLab은 저장소 내 위키를 지원하지만, Moin 위키를 마이그레이션할 이유는 없습니다.
  • 기존 GitHub 미러 처리: 공식 업스트림 브랜치가 Git에 기본적으로 호스팅되면 기존 GitHub 미러를 다시 생성해야 할 수 있습니다.

참고 자료 (References)

  • Open Hub Statistics
  • Hg-Git mercurial plugin
  • https://about.gitlab.com

이 문서는 퍼블릭 도메인(public domain)에 있습니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments