Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 512 – hg.python.org에서 GitHub로 이전하기

Author:
Brett Cannon <brett at python.org>
Discussions-To:
Core-Workflow list
Status:
Final
Type:
Process
Created:
17-Jan-2015
Post-History:
17-Jan-2016, 19-Jan-2016, 23-Jan-2016
Table of Contents

번역·라이선스 안내

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

Note

CPython의 개발 프로세스는 2017-02-10에 https://github.com/python/cpython 으로 이전되었습니다.

초록

이 PEP는 Python의 개발 프로세스를 hg.python.org [1]에서 호스팅되는 Mercurial [3]에서 GitHub [2]의 Git [4]으로 이전하는 데 필요한 단계를 설명합니다. 이 PEP의 최소 목표를 달성하면 Python의 개발 프로세스가 현재만큼 생산적일 수 있어야 하며, 확장 목표까지 달성하면 개발 프로세스가 현재 상태보다 개선되어야 합니다.

근거

2014년에 Python의 독자적인 개발 프로세스가 걸림돌이 되고 있다는 사실이 분명해졌습니다. 예를 들어 외부 기여자가 버그 수정을 제출하여 최종적으로 커밋되기까지의 기본 단계는 다음과 같았습니다.

  1. bugs.python.org [5]에 해당 버그에 대한 이슈를 엽니다.
  2. hg.python.org [1]에서 CPython 소스 코드를 체크아웃합니다.
  3. 수정합니다.
  4. 패치를 업로드합니다.
  5. 우리가 포크한 Rietveld 코드 리뷰 도구 [6]를 사용하여 코어 개발자가 패치를 리뷰하게 합니다.
  6. 패치를 내려받아 여전히 깔끔하게 적용되는지 확인합니다.
  7. 테스트 스위트를 수동으로 실행합니다.
  8. 필요에 따라 NEWS, ACKS, “What’s New” 문서를 갱신합니다
  9. 병합 경쟁을 피하기 위해 변경 사항을 pull 합니다.
  10. 변경 사항을 수동으로 커밋합니다.
  11. 변경 사항이 버그 수정 릴리스를 위한 것이라면 개발 중인 브랜치로 병합합니다.
  12. 테스트 스위트를 다시 수동으로 실행합니다.
  13. 병합을 커밋합니다.
  14. 변경 사항을 푸시합니다.

이는 코어 개발자에게 매우 무겁고 수작업이 많은 프로세스입니다. 간단한 경우에도 생략할 수 있는 것은 기껏해야 코드 리뷰 단계뿐인데, 문서는 여전히 빌드해야 하기 때문입니다. 이로 인해 코어 개발자들이 제출 속도를 따라잡을 만큼 빠르게 밀린 작업을 처리하지 못하여 패치가 이슈 트래커에 방치되는 일이 생겼습니다. 이는 다시 관심 부족에 따른 좌절감으로 외부 기여를 위축시키는 부작용을 낳았는데, 이는 프로젝트의 지속 가능한 미래에 역행하므로 기업의 후원이 없는 오픈 소스 프로젝트에는 위험한 문제입니다. bugs.python.org [5]에 패치를 업로드할 수 있게 하는 것은 외부 기여자에게는 간단할 수 있지만, 코어 개발자가 다루기에는 더할 나위 없이 느리고 부담스럽습니다.

이에 따라 2014년 말에 새로운 개발 프로세스로의 이전이 필요하다는 결정이 내려졌습니다. 새로운 워크플로를 제안하는 PEP를 요청하였고, 최종적으로 각각 GitHub [2]와 GitLab [7]을 제안하는 PEP 481과 PEP 507두 개가 나왔습니다.

2015년 한 해 동안 이 제안들을 간헐적으로 다듬으면서, core-workflow(코어 워크플로) 메일링 리스트 [8]에서 각 제안이 서로 어떻게 다른지 세부 사항을 파악하려고 했습니다. PyCon US 2015에서도 새로운 기여자에게 요구되는 인지적 부담과 코어 개발자가 패치를 살펴보기까지 걸리는 시간 때문에 커뮤니티가 우리의 프로세스에 다소 불만을 느끼고 있음이 드러났습니다(그러한 불만의 예로 PyCon US 2015에서 있었던 Guido van Rossum의 기조연설 [9] 마지막 부분을 참고하십시오).

2016년 1월 1일, Brett Cannon은 개발 프로세스를 GitHub로 옮기기로 결정했습니다. GitHub를 선택한 주요 이유는 다음과 같습니다 [10]:

  • 자체 인프라를 유지 관리하는 일은 자원봉사자들에게 부담이 되어 왔습니다(예를 들어, 현재 관리되지 않는 Rietveld [6]의 자체 포크를 사용하고 있습니다).
  • 자체 워크플로는 코어 개발자에게 시간이 매우 많이 드는 작업입니다(이를 지원할 자동화 도구가 충분히 만들어지지 않았습니다).
  • 자체 워크플로는 외부 기여자에게 걸림돌이 됩니다(CPython에만 있는 고유한 개발 프로세스를 익히는 데 시간이 필요하므로 진입 장벽으로 작용합니다).
  • GitLab이 오픈 소스라는 점 외에는 GitLab을 GitHub와 차별화하는 기능이 없습니다.
  • 코어 개발자와 외부 기여자 모두 GitLab보다 GitHub에 훨씬 더 익숙합니다.
  • 우리의 BDFL은 GitHub를 선호합니다(BDFL 본인이야말로 자신의 의견이 중요해서는 안 된다고 가장 먼저 말할 사람이겠지만, 결정을 내리는 사람은 BDFL이 계속 참여하도록 장려하려면 BDFL이 자신의 프로그래밍 언어의 워크플로를 편안하게 느끼는 것이 중요하다고 판단했습니다).

GitHub로의 이전을 나타내는 비공식 로고까지 이미 있습니다 [22].

이번 이전의 궁극적인 목표는 코어 개발자가 WiFi에 연결된 태블릿의 브라우저 안에서 어떤 개발 프로세스를 사용하여, 외부 기여의 제출부터 해당 기여를 커밋하기까지의 모든 단계를 진행할 수 있을 정도로 개발 프로세스를 개선하는 것입니다(이것이 반드시 GitHub의 기본 워크플로를 뜻하지는 않습니다). 최종 방안은 외부 기여자가 GitHub를 사용하지 않기로 선택하더라도 기여할 수 있도록 할 것입니다(다만 기능이 동등하다는 보장은 없습니다).

이전할 저장소

hg.python.org [1]에는 많은 저장소가 호스팅되어 있지만, 옮겨야 할 핵심 저장소는 다섯 개뿐입니다:

  1. devinabox [12] (완료)
  2. 벤치마크 [11] (건너뜀)
  3. peps [13] (완료)
  4. devguide [14] (완료)
  5. cpython [15]

devinabox 저장소는 코드로만 이루어져 있습니다. peps와 devguide 저장소는 웹 페이지 생성을 포함합니다. 그리고 cpython 저장소에는 bugs.python.org [5]와의 연동에 관한 특별한 요구 사항이 있습니다.

마이그레이션 계획

이전 계획은 Repositories to Migrate 절에 나열된 저장소를 이전하는 데 필요한 사항을 기준으로 여러 절로 나뉩니다. 각 절에 명시된 요구 사항이 완료되면 관련 저장소의 이전을 막고 있던 장애물이 해소됩니다. 각 절은 순서대로 완료될 것으로 예상하지만, 한 절 안의 요구 사항까지 반드시 순서대로 완료될 필요는 없습니다.

코드 전용 저장소의 요구 사항

이 절의 요구 사항이 완료되면 devinabox 저장소를 GitHub로 옮길 수 있습니다.

‘Python core’ 팀 만들기

권한을 관리하기 위해 python 조직 [16]의 일부로 ‘Python core’ 팀을 만듭니다. 이전되는 모든 저장소에는 ‘Python core’ 팀이 쓰기 권한 [17]과 함께 추가됩니다. 이전에 hg.python.org에서 SSH 키를 관리할 권한이 있던 사람은 누구나 ‘Python core’ 팀의 팀 유지 관리자가 됩니다.

Mercurial 저장소를 Git으로 옮기는 명령 정의하기

GitHub로 옮기면 Git [4]으로도 옮기게 되므로, Mercurial 저장소를 Git으로 변환하는 데 어떤 도구와 명령을 사용할지 결정해야 합니다. 이 마이그레이션을 위해 따로 개발한 도구는 https://github.com/orsenthil/cpython-hg-to-git 에 있습니다.

CLA 시행

모든 오픈 소스 프로젝트에서 중요한 일 가운데 하나는 소스 코드에 적절한 라이선스를 부여할 수 있게 하는 것입니다. 그러려면 기여하는 모든 사람이 기여자 라이선스 동의서(CLA) [18]에 서명했는지 확인해야 합니다. 지금까지는 코어 개발자가 bugs.python.org [5]에서 사용자 이름 옆에 *가 있는지 확인하는 방식으로 기여된 코드의 CLA 서명 여부를 시행해 왔습니다. 이번 마이그레이션에서는 먼저 기여자의 CLA 서명 여부를 자동으로 확인하고 시행할 계획입니다.

bugs.python.org에 GitHub 사용자 이름 지원 추가

CLA 서명 추적을 PSF가 직접 관리할 수 있도록, PSF CLA에 누가 서명했는지는 앞으로도 해당 사용자의 bugs.python.org 사용자 프로필에 표시하는 방식으로 추적합니다. 따라서 한 사람의 bugs.python.org [5] 계정과 GitHub 계정을 연결해야 하며, 이 연결은 사용자 프로필에 새로 추가하는 필드로 이루어집니다. 이는 곧 기여자가 CLA에 서명하고 GitHub로 기여하려면 GitHub [2] 계정과 bugs.python.org 계정이 모두 있어야 한다는 뜻입니다.

GitHub 사용자 이름이 CLA에 서명한 사람의 것인지 bugs.python.org에 질의할 수 있는 API가 제공됩니다. 예를 들어 http://bugs.python.org/user?@template=clacheck&github_names=brettcannon,notanuser 에 GET 요청을 보내면 JSON 딕셔너리가 반환됩니다. 이 딕셔너리는 요청한 사용자 이름을 키로 하며, 값은 CLA에 서명했으면 true, 서명하지 않았으면 false, 해당하는 GitHub 사용자 이름을 찾지 못했으면 null입니다.

CLA 서명을 시행하는 봇

GitHub 계정이 CLA 서명 여부 데이터를 가진 bugs.python.org [5] 계정과 연결되어 있으면, 봇이 GitHub의 풀 리퀘스트를 모니터링하면서 기여자가 CLA에 서명했는지 표시할 수 있습니다.

사용자가 CLA에 서명했으면 봇은 이슈에 긍정 레이블(예: “CLA signed”라고 적힌 녹색 레이블)을 붙여 해당 풀 리퀘스트에 CLA 문제가 없다고 표시합니다. 기여자가 CLA에 서명하지 않았으면 풀 리퀘스트에 부정 레이블(예: “CLA not signed”라고 적힌 빨간색 레이블)이 붙고, 해당 풀 리퀘스트는 GitHub의 상태 API로 차단됩니다. 기여자에게 bugs.python.org 계정이 없을 때에도 부정 레이블이 붙습니다. 긍정적인 경우와 부정적인 경우 모두에 레이블을 쓰면 봇이 실패했을 때 대체 신호가 되므로, 거짓 양성이나 거짓 음성이 생기는 것을 막을 수 있습니다. 또한 CLA 관련 레이블을 지우기만 하면 봇을 쉽게 다시 실행할 수 있습니다(코드가 변경될 때만 실행되는 GitHub 상태 검사 [30]는 그렇지 않습니다).

우리에게 맞는 기존 봇이 없으므로, 봇은 새로 작성하여 Heroku [29]에서 운영합니다. 비동기 프로그래밍의 좋은 예가 되도록 Python 3.5를 대상으로 작성합니다. 봇의 코드는 Knights Who Say Ni 프로젝트 [31]에 있습니다.

이전 저장소를 읽기 전용으로 만들기

이제 이전 저장소가 된 Mercurial 저장소에서 .hg/hgrc의 [hooks] 섹션을 다음과 같이 수정하면:

pretxnchangegroup.reject = echo " * This repo has been migrated to github.com/python/peps and does not accept new commits in Mercurial!" 2>&1; exit 1

저장소가 읽기 전용이 됩니다.

웹 관련 저장소에 대한 요구 사항

devguide [14] 저장소와 peps [13] 저장소는 웹 페이지를 생성하는 데 쓰이므로, 새 Git 저장소에서 가져오도록 각 프로세스를 수정해야 합니다.

cpython 저장소에 대한 요구 사항

현재 hg.python.org [1]에 있는 저장소 가운데 가장 활발하고 중요한 저장소는 당연히 cpython 저장소 [15]입니다. cpython 저장소는 중요하고 자주 쓰이므로, 이 PEP에서 다루는 다른 저장소들보다 GitHub로 옮기기 전에 갖춰야 할 도구가 더 많습니다.

풀 리퀘스트를 커밋하는 절차 문서화

새 개발 워크플로를 선택하는 과정에서 선형 이력을 채택하기로 결정했습니다. 사람들은 서로 관련 없는 여러 커밋이 하나의 변경을 나타내는 병합 커밋으로 이어지는 방식보다 하나의 커밋이 하나의 변경을 나타내는 방식을 선호했습니다. 따라서 GitHub 풀 리퀘스트의 편리한 “Merge” 버튼은 병합 커밋을 만들지 않고 squash 커밋만 수행하도록 설정됩니다.

bugs.python.org [5]에 업로드된 패치 파일로 기여를 커밋할 때 사용할 두 번째 권장 명령어 모음도 작성됩니다. 이 방식도 당연히 선형 이력을 유지하는 데 도움이 되지만, 패치 작성자가 저작자로 표시되도록 해야 합니다.

코어 개발자에게 지침으로 제공할 정확한 명령어 순서는 아직 정해지지 않았습니다: Git CLI commands for committing a pull request to cpython.

풀 리퀘스트를 이슈에 연결하기

과거에는 모든 외부 기여가 파일로 업로드되었으므로 외부 기여는 bugs.python.org [5]의 이슈에 첨부되었습니다. 코어 개발자가 변경을 직접 커밋한 경우에는 커밋 메시지 맨 앞에 Issue # 형식으로 이슈 번호를 적으면 해당 커밋으로 연결되는 댓글이 이슈에 게시되었습니다.

풀 리퀘스트를 이슈에 연결하기

수정이 언제 제안되었는지 추적하려면 풀 리퀘스트와 이슈를 연관시켜야 합니다. 하나의 이슈를 해결하는 데 여러 풀 리퀘스트가 필요할 수 있으므로 이 연관 관계는 다대일이어야 합니다(엄밀히 말하면 하나의 수정이 여러 이슈를 해결하는 경우도 있으므로 다대다 연관 관계여야 하지만, 그런 경우는 꽤 드물고 이슈 트래커의 Superseder 필드로 이슈들을 하나로 병합할 수 있습니다).

풀 리퀘스트와 이슈는 이슈 번호를 감지하여 연관시킵니다. 풀 리퀘스트의 제목이나 메시지 본문에 이슈가 적혀 있으면 bugs.python.org [5]에서 연결이 만들어집니다. 연관이 성공적으로 만들어졌음을 알리기 위해 풀 리퀘스트에 레이블이나 메시지 같은 눈에 보이는 알림이 추가됩니다.

커밋이 이루어지면 이슈에 알리기

커밋이 이루어지면 해당 이슈를 갱신하여 이 사실을 반영해야 합니다. 이 기능은 커밋이 풀 리퀘스트에서 왔는지 직접 커밋되었는지와 관계없이 동작해야 합니다.

커밋 ID를 URL에 매핑하는 연결 서비스 갱신하기

현재는 cpython 저장소 [15]의 Subversion 또는 Mercurial 사본의 리비전 ID를 https://hg.python.org/lookup/ 에 사용하면 Mercurial 저장소에 있는 해당 리비전의 URL로 리디렉션됩니다. URL 재작성기는 Git 저장소로 리디렉션하고 Git 저장소용으로 새로 만들어진 리비전 ID를 지원하도록 갱신되어야 합니다.

가장 유력한 설계는 마이그레이션이 끝나면 모든 Mercurial 체인지셋 번호를 정적으로 파악해 두는 것입니다. 그런 다음 조회 코드는 7자리에서 40자리까지의 16진수 해시를 받아들이도록 갱신됩니다. 길이가 12자리 또는 40자리인 16진수는 모두 Mercurial 체인지셋 번호와 비교됩니다. 번호가 일치하지 않거나 길이가 7자리에서 40자리 사이의 다른 값이면 Git 해시로 간주합니다.

Git은 7자리 이상의 해시로 일치 여부를 판별하므로, bugs.python.org commit number rewriter도 7자리까지 짧은 해시를 받아들이도록 갱신되어야 합니다.

sys._mercurial 폐지하기

Python을 더 이상 Mercurial에서 관리하지 않게 되면 sys._mercurial 속성은 ('CPython', '', '')를 반환하도록 변경되어야 합니다. 같은 용도로 쓸 수 있는 동등한 sys._git 속성이 추가됩니다.

devguide 갱신하기

devguide에 새 워크플로의 세부 사항을 반영해야 합니다. 이 작업은 실제 마이그레이션이 이루어질 때까지 별도의 브랜치에서 진행될 가능성이 높습니다.

PEP 101 갱신

릴리스 절차는 필요에 따라 갱신해야 합니다.

선택적 계획 기능

cpython 저장소 [15]의 마이그레이션이 끝나면 모든 저장소가 GitHub [2]로 옮겨진 상태가 되며, 개발 절차는 마이그레이션 전과 동등한 수준이 되어야 합니다. 그러나 이번 마이그레이션의 핵심 이유는 개발 절차를 개선하여 그 어느 때보다 더 나은 상태로 만드는 것입니다. 이 절에서는 개선 방법에 관한 몇 가지 계획을 설명합니다.

참고로 bugs.python.org [5]의 전반적인 기능 계획은 (이번 마이그레이션과 무관한 계획까지 포함하여) 별도의 위키 페이지 [23]에서 추적된다는 점을 언급해 둡니다.

Misc/NEWS 처리

전통적으로 Misc/NEWS 파일 [19]은 여러 Python 릴리스에 걸친 변경 사항에서 문제가 되어 왔습니다. 예를 들어 3.5와 3.6 사이에서 변경 사항을 커밋할 때 Misc/NEWS 파일에서만 병합 충돌이 발생하는 경우가 자주 있습니다. 실제로 이런 일이 너무 흔해서 devguide의 예시 안내에서도 Misc/NEWS 파일의 충돌을 해결하는 방법을 명시적으로 언급하고 있습니다 [21]. 도구 현대화의 일환으로 Misc/NEWS 파일을 다루는 작업이 간소화될 것입니다.

계획된 방식은 뉴스 항목마다 해당 항목의 텍스트를 담은 개별 파일을 사용하는 것입니다. 이 방식에서는 각 기능 릴리스마다 뉴스 항목용 디렉터리를 두고, 그 디렉터리 안에 해당 항목이 해결한 이슈의 이름이나 타임스탬프 값(충돌을 방지함)으로 이름 붙인 별도의 파일을 만듭니다. 뉴스 항목 파일은 여전히 고유한 이름을 가지며 수정 사항이 포함된 최신 버전의 디렉터리에 있으므로, 브랜치 간 병합에도 문제가 없습니다. 스크립트가 어느 디렉터리에 있든 모든 뉴스 항목 파일을 수집하여 적절한 뉴스 파일을 생성합니다(파일이 존재한다는 사실만으로 해당 항목이 그 릴리스에 속함을 나타내기에 충분하므로 릴리스 디렉터리는 무시해도 됩니다). 분류는 새 항목 파일 자체에 키워드를 넣어 수행하거나, 각 릴리스 디렉터리 안에 뉴스 항목 분류별 하위 디렉터리를 두어 수행할 수 있습니다(또는 중요한 정보는 체계적으로 정리된 “What’s New” 문서에 담기므로 뉴스 항목 분류를 없앨 수도 있습니다). 이 방식의 장점은 변경 사항을 실제로 변경된 코드와 함께 유지한다는 것입니다. 또한 메시지를 해당 변경을 도입한 커밋의 일부로 묶어 줍니다. CLI를 통해 만든 커밋의 경우, 파일 생성을 돕는 스크립트를 제공할 수 있습니다. 봇 기반 시나리오에서는 병합 봇이 특정 뉴스 항목을 지정하는 방법을 제공하고 평탄화된 커밋의 일부로 파일을 생성할 수 있습니다(특정 뉴스 항목이 지정되지 않은 경우 커밋 메시지의 첫 줄을 사용하는 기능도 지원할 가능성이 높습니다). 웹 기반 워크플로를 사용하는 경우, 상태 검사를 통해 풀 리퀘스트에 새 항목 파일이 있는지 확인하여 파일이 누락되었음을 알려 주는 역할을 하게 할 수 있습니다. 이 방식을 위한 코드는 이전에 Mercurial 워크플로용으로 http://bugs.python.org/issue18967 에서 작성된 적이 있습니다. 또한 https://pypi.python.org/pypi/towncrier, https://github.com/twisted/newsbuilder, http://docs.openstack.org/developer/reno/ 같은 커뮤니티 도구도 있습니다.

2016년 9월 Python 코어 개발자 스프린트에서의 논의를 거쳐, 이 PEP의 Rejected Ideas 절에 설명된 기각된 방식들 대신 이 방식으로 결정되었습니다. 여러 선택지 중 별도 파일 방식이 동기가 된 문제를 해결하면서도 유연성과 도구 지원 가능성 사이에서 적절한 균형을 이루는 것으로 보입니다.

이 작업은 https://github.com/python/core-workflow/issues/6 에서 추적되고 있습니다.

Misc/ACKS 처리

전통적으로 Misc/ACKS 파일 [20]은 수작업으로 관리되어 왔습니다. 그러나 Git은 커밋마다 committer 값뿐만 아니라 author 값도 지원하므로, 커밋의 작성자 정보가 코드 자체 이력의 일부가 될 수 있습니다.

따라서 Misc/ACKS를 수동으로 관리하는 일은 선택 사항이 됩니다. 모든 작성자와 커미터의 이름을 수집하여 Git으로 이전하기 전에 등재된 모든 이름과 함께 Misc/ACKS에 병합하는 스크립트를 작성할 것입니다. 이 스크립트를 실행하는 것은 릴리스 절차의 일부가 됩니다.

이 스크립트는 마지막 실행 이후 기여한 모든 사람의 목록도 생성해야 합니다. 이를 통해 특정 릴리스에 기여한 사람들의 목록을 확보하여 그들에게 명시적으로 감사를 표할 수 있습니다.

이 작업은 https://github.com/python/core-workflow/issues/7 에서 추적하고 있습니다.

https://git.python.org 만들기

현재 hg.python.org [1]가 Python의 Mercurial 저장소를 가리키는 것처럼, git.python.org는 Git 저장소에 대해 같은 역할을 해야 합니다.

풀 리퀘스트 데이터 백업

GitHub [2]를 코드 호스팅과 코드 리뷰에 사용할 것이므로, 이 두 가지를 백업해야 합니다. 코드 호스팅의 경우, 얕은(shallow) 클론이 아닌 모든 Git [4] 클론에는 저장소의 전체 이력이 포함되므로 백업이 암묵적으로 이루어지며, 따라서 저장소의 백업이 여러 개 존재하게 됩니다.

코드 리뷰 이력에는 저장소 자체와 같은 암묵적 백업 메커니즘이 없습니다. 따라서 GitHub에 어떤 문제가 생기더라도 코드 리뷰 이력을 잃지 않도록 매일 백업해야 합니다. 또한 이는 GitHub가 하룻밤 사이에 사라지더라도 GitHub에서 다른 코드 리뷰 시스템으로 이전할 수 있음을 보장하는 데 도움이 됩니다.

체리픽 풀 리퀘스트를 생성하는 봇

브랜치를 순방향으로 병합하는 대신 체리픽으로 작업하기로 결정했으므로, 여러 브랜치에 영향을 미치는 모든 풀 리퀘스트에 대해 체리픽 기반의 풀 리퀘스트를 생성하는 봇이 있으면 편리할 것입니다. 가장 유력한 설계는 풀 리퀘스트를 어느 브랜치로 체리픽해야 하는지 나타내는 핵심 레이블이 붙은 병합된 풀 리퀘스트를 감시하는 봇입니다. 그러면 봇은 각 레이블에 대해 체리픽 풀 리퀘스트를 생성하고, 풀 리퀘스트가 생성될 때마다 해당 레이블을 제거합니다(이를 통해 자동 체리픽이 실패한 경우를 쉽게 감지할 수 있습니다).

이 작업은 https://github.com/python/core-workflow/issues/8 에서 추적하고 있습니다.

풀 리퀘스트 커밋 큐

이것은 승인된 풀 리퀘스트를 순차적으로 적용하고, 테스트 스위트를 실행하여 커밋들이 서로 간섭하지 않았는지 검증하며, 테스트 실행이 실패하면 커밋을 되돌립니다. 테스트 속도를 높이기 위해, 패치들이 함께 잘 동작할 것이라는 낙관적 가정하에 마지막 테스트 실행 이후 커밋된 모든 패치를 한꺼번에 적용하여 단일 테스트 실행으로 검증할 수 있습니다. 테스트가 불안정한 경우를 대비해 테스트를 다시 실행하는 메커니즘이 필요합니다. “test failed” 레이블을 제거하는 방식이든, 코어 개발자가 또 다른 테스트 이벤트를 실행할 수 있는 웹 인터페이스든 방식은 상관없습니다.

이 봇의 아이디어나 기반은 Homu [24]나 Zuul [25] 같은 기존 봇에서 가져올 수 있습니다.

명령을 내리기 위해 이 봇에 붙일 이름은 미해결 문제입니다: Naming the bots.

CI 서비스

GitHub [2]에서 호스팅되는 오픈 소스 프로젝트를 무료로 지원하는 다양한 CI 서비스가 있습니다. 몇 가지 CI 서비스를 시험해 본 후, Travis [26]를 사용하기로 결정했습니다.

현재 Python의 CI 서비스는 Pypatcher [28]입니다. IRC에서 bugs.python.org [5]의 패치를 시험해 달라고 요청할 수 있습니다. 결과는 https://ci.centos.org/job/cPython-build-patch/ 에서 확인할 수 있습니다.

이 작업은 https://github.com/python/core-workflow/issues/1 에서 추적하고 있습니다.

테스트 커버리지 보고서

Python 표준 라이브러리의 최신 테스트 커버리지 보고서는 매우 유용할 것입니다. 이런 보고서는 생성하는 데 상당한 시간이 걸릴 수 있기 때문입니다.

오픈 소스 프로젝트에 테스트 커버리지를 무료로 제공하는 기존 서비스가 몇 가지 있습니다. 최종적으로 Codecov [27]가 가장 좋은 선택지로 선정되었습니다.

이 작업은 https://github.com/python/core-workflow/issues/2 에서 추적하고 있습니다.

풀 리퀘스트 댓글을 이슈에 알리기

현재 개발 프로세스에는 Rietveld [6]에 리뷰 댓글이 남겨졌을 때 bugs.python.org [5]의 이슈에 알리는 과정이 포함되어 있지 않습니다. 이를 개선하여, 사람들이 GitHub [2]가 아닌 bugs.python.org의 댓글만 구독하더라도 관련 풀 리퀘스트의 리뷰 댓글과 관련해 GitHub에서 일어나는 일을 알 수 있게 된다면 좋을 것입니다. 현재 검토 중인 방안은 일정 시간(예: 15분 또는 30분. 다만 이제 GitHub가 리뷰를 지원하므로 시간 요소는 필요하지 않을 수도 있습니다) 동안 리뷰 댓글이 하나 이상 달렸을 때 bugs.python.org의 관련 이슈에 댓글을 게시하는 것입니다. 이렇게 하면 GitHub와 bugs.python.org 이메일 알림을 모두 받는 사람들의 이메일 양을 줄이면서도, bugs.python.org만 팔로우하는 사람들이 대응해야 할 리뷰 댓글이 있을 수 있다는 사실을 확실히 알 수 있습니다.

bugs.python.org에서 GitHub를 로그인 제공자로 사용할 수 있도록 허용하기

현재 bugs.python.org [5]에서는 Google, Launchpad 또는 OpenID 자격 증명으로 로그인할 수 있습니다. 이를 GitHub 자격 증명까지 확장하면 좋을 것입니다.

웹 콘텐츠 재생성을 위한 웹훅

https://docs.python.org/, https://docs.python.org/devguide, https://www.python.org/dev/peps/ 의 콘텐츠는 모두 이번 마이그레이션의 일환으로 이전될 저장소 중 하나에 보관된 파일로부터 만들어집니다. 따라서 예를 들어 cronjob이 실행되기를 기다리는 대신, 기반이 되는 파일이 변경될 때 해당 웹 콘텐츠를 다시 빌드하도록 적절한 웹훅을 설정하면 좋을 것입니다.

문서가 Sphinx 프로젝트라면 사이트가 Read the Docs에 비공식 미러를 둘 수 있으므로 이 문제를 부분적으로 해결할 수 있습니다. 예를 들면 http://cpython-devguide.readthedocs.io/ 가 있습니다.

이 작업은 https://github.com/python/core-workflow/issues/9 에서 추적하고 있습니다.

웹 콘텐츠에서 그 콘텐츠를 생성한 파일로 연결하는 링크 제공하기

파일로부터 생성된 문서에서 문제를 발견한 사람들을 위해, 각 페이지에 해당 페이지의 내용을 담고 있는 GitHub [2] 상의 파일로 연결되는 링크가 있으면 도움이 될 것입니다. 그러면 철자 오류와 같은 간단한 문제를 수정하는 풀 리퀘스트를 빠르게 보낼 수 있습니다.

이 작업은 http://bugs.python.org/issue28929 에서 추적하고 있습니다.

문서의 일부를 별도의 저장소로 분리하기

https://docs.python.org 의 문서 중 일부는 코드와 함께 변경되지만, 다른 부분은 상당히 정적이며 CPython 코드 자체와 긴밀하게 결합되어 있지 않습니다. 문서의 다음 섹션들이 이처럼 변경이 느리고 결합도가 낮은 범주에 해당합니다:

문서의 이러한 부분들을 별도의 저장소로 분리하면 유지 보수가 간단해집니다. 또한 커밋 권한을 가진 사람의 범위를 넓혀 유지 보수를 더 쉽게 할 수 있습니다.

What’s New 문서를 분리하자는 제안도 있었습니다. 그러려면 What’s New 갱신을 잊어버리기 어려운 워크플로를 만들 수 있는지 결정해야 합니다(예를 들어 PR에 “What’s New needed” 같은 레이블을 붙이는 방식이 있습니다).

Git 저장소 백업

꼭 필요한 것은 아니지만, 재해에 대비하여 여러 Git 저장소의 공식 백업을 마련해 두면 좋습니다. 이것이 가치 있는 일인지 불필요한 일인지는 PSF 인프라 위원회가 결정합니다.

새 코어 개발자 후보 발굴

Python 개발 팀에는 새 코어 개발자를 선정하는 오래된 지침이 있습니다. 이 지침의 핵심은 승인된 패치를 여러 개 기여했어야 하며, 그 패치들이 Python 개발 프로세스를 이해하고 있음을 보여 줄 만큼 품질과 규모를 갖추어야 한다는 것입니다. 패치 수락률을 추적하고 보고서를 생성하는 봇을 작성할 수 있습니다. 이 보고서는 코어 개발자 후보로 고려할 만한 기여자를 찾는 데 도움이 됩니다. 모든 git 커밋의 committer 필드가 올바르게 채워져 있기만 하면, 이 작업에 GitHub 통합이 꼭 필요한 것도 아닙니다.

이 작업은 https://github.com/python/core-workflow/issues/10 에서 추적하고 있습니다.

상태

devinabox [12] 저장소 마이그레이션 요구 사항:

빌드 단계를 갱신해야 하는 저장소:

cpython 저장소 [15]

필수:

선택적 기능:

미해결 문제

이 PEP에서 미해결 문제란 어떤 문제에 어떻게 접근하거나 해결할지 결정을 내려야 하는 사안을 말합니다. 미해결 문제에는 특정 코드를 누가 작성할 것인지와 같은 조율 문제는 포함되지 않습니다.

hg.python.org의 향후 처리

코드 저장소가 Git [4]으로 이전됨에 따라, 기술적으로는 hg.python.org [1]를 계속 운영할 필요가 없습니다. 그렇기는 하지만, 커뮤니티의 일부 구성원은 이를 Git 저장소의 Mercurial [3] 미러로 계속 운영하기를 원합니다. 다른 이들은 여전히 미러를 원하지만, Git을 사용하는 미러를 원한다고 말했습니다.

hg.python.org를 유지하는 것은 필수가 아니므로, 이를 계속 운영하는 데 시간과 자원을 들일지는 PSF 인프라 위원회가 결정하게 됩니다. 위원회는 PSF 인프라에서 Git 미러를 호스팅할지도 선택할 수 있습니다.

내려진 결정에 따라, 다른 부수적인 저장소들은 이전이 강제되거나, 그냥 hg.python.org에 남는 것을 선택할 수 있게 됩니다.

cpython에 풀 리퀘스트를 커밋하기 위한 Git CLI 명령

Git [4]은 코어 개발자에게 새로운 버전 관리 시스템일 수 있으므로, 사람들이 실행해야 할 명령을 문서로 정리해야 합니다. 또한 이 명령들은 풀 리퀘스트 작성자의 기여를 적절히 표시하면서 선형 히스토리를 유지해야 합니다.

bugs.python.org [5]에 업로드된 패치 파일로 작업할 때를 위한 별도의 명령 세트도 필요합니다. 이 경우 선형 히스토리는 암묵적으로 유지되지만, 기여 표시를 반드시 유지하거나 추가해야 합니다.

봇 이름 짓기

이름 짓기는 엄청난 규모의 소모적인 논쟁으로 번질 수 있으므로, 여러 봇의 최종 이름은 Brett Cannon이 정합니다(봇 자체의 프로젝트 이름은 무엇이든 상관없으며, 이는 순전히 봇에게 명령을 내릴 때 사용하는 이름이나 계정 이름에 관한 것입니다). 이름은 Monty Python에서 따와야 하는데, Python이라는 이름이 이 코미디 그룹에서 유래했으므로 이는 무척 잘 어울리는 일입니다.

기각된 아이디어

Python 2와 Python 3 저장소 분리

Python 2와 Python 3에 대해 별도의 저장소를 두는 것이 바람직한지 논의되었습니다. 이렇게 하면 전체 저장소 크기가 줄어들어, 인터넷 연결이 느리거나 대역폭 제한이 작은 사람들에게 도움이 되리라는 생각이었습니다.

결국 CPython의 모든 히스토리를 하나의 저장소에 그대로 유지하는 것이 운영상 더 쉽다고 결정되었습니다.

여러 릴리스에 걸친 변경을 버그 수정 브랜치에 먼저 커밋하기

현재 개발 프로세스에서는 변경 사항을 가장 오래된 브랜치에 먼저 커밋한 뒤 기본 브랜치까지 병합해 올리므로, 이 워크플로를 계속 유지해야 하는지에 대한 의문이 제기되었습니다. 결국 가장 최신 브랜치에 커밋한 뒤 변경 사항을 이전 브랜치들로 체리픽하는 방식이 가장 좋다고 결정되었는데, 대부분의 사람들은 본능적으로 가장 최신 브랜치에서 작업하며 이것이 Git [4]을 사용할 때 더 일반적인 워크플로이기 때문입니다.

체리픽은 브라우저 내 워크플로에서 봇과 함께 사용하기에도 더 적합합니다. 병합해 올리는 시나리오에서는 봇에게 병합을 요청했는데 실패한 경우, 주 커밋을 그대로 허용했다면 병합 충돌을 즉시 해결해야 하고, 그렇지 않다면 모든 병합을 처리할 수 있을 때까지 커밋 전체를 미뤄야 합니다. 체리픽 워크플로에서는 병합에 실패한 체리픽을 미뤄 두고 주 커밋은 진행할 수 있습니다. 이를 통해 충돌하는 병합을 처리하는 작업을 분담할 수도 있습니다.

마지막으로, 체리픽은 병합 경쟁을 피하는 데 도움이 될 것입니다. 현재는 여러 브랜치에 걸친 작업을 할 때 이전 브랜치에 커밋하고, 경우에 따라 default 브랜치를 나타내는 다른 클론에 푸시하고, 변경 사항을 병합한 뒤 업스트림에 푸시하기까지 시간이 걸립니다. 체리픽은 이 과정을 분리해 주며, 체리픽을 따로 수행할 수 있으므로 여러 브랜치에 걸친 변경을 서둘러 처리할 필요가 없습니다.

커밋 로그로부터 Misc/NEWS 생성하기

Handling Misc/NEWS를 둘러싼 논의의 일환으로, 커밋 로그 자체에서 이 파일을 도출하자는 제안이 나왔습니다. 이 시나리오에서는 커밋 메시지의 첫 줄을 해당 변경에 대한 뉴스 항목으로 간주합니다. 변경에 뉴스 항목이 필요한지를 판단하기 위해 이슈 번호가 기재되어 있는지 여부 같은 휴리스틱을 사용하게 됩니다.

일부 코어 개발자들이 뉴스 항목을 커밋 메시지와 별도로 작성하는 것을 선호하여 이 아이디어는 기각되었습니다. 이들이 내세우는 인자는 커밋 메시지의 첫 줄과 뉴스 항목의 첫 줄이 간결성, 담아야 할 내용 등의 측면에서 요구 사항이 서로 다르다는 것입니다.

bugs.python.org에서 Misc/NEWS 도출하기

NEWS 파일 문제에 대해 기각된 해결책 중 하나는 bugs.python.org [5]에서 항목을 지정하는 것이었습니다. 이렇게 하면 “resolved”로 표시된 이슈는 이슈 트래커의 “news” 필드에 뉴스 항목이 추가될 때까지 닫을 수 없게 됩니다. 뉴스 항목을 이슈에 연결하면 뉴스 항목을 작성할 만한 모든 변경에 대응하는 이슈가 반드시 존재하게 된다는 이점이 있습니다. 또한 이슈의 Component 필드 덕분에 뉴스 항목의 분류가 자동으로 이루어집니다. 이슈의 Versions 필드는 뉴스 항목을 영향을 받은 Python 릴리스와도 연결해 줍니다. 릴리스와 관련된 새 항목을 bugs.python.org에 조회하고 코드 저장소에 체크인해야 할 출력을 생성하는 스크립트를 작성하게 됩니다. 이 방식은 커밋이 CLI로 이루어졌는지 봇으로 이루어졌는지와 무관합니다. 단점은 변경을 실제로 수행한 커밋과 뉴스 항목이 서로 다른 곳(이 경우 GitHub와 bugs.python.org)에 존재하게 되어 둘 사이에 단절이 생긴다는 점입니다. 즉, 커밋을 한 뒤에는 bugs.python.org로 돌아가 뉴스 항목을 추가하는 것을 잊지 않아야 합니다.

참고 문헌