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는 hg.python.org [1]에 호스팅된 Mercurial [3]에서 GitHub [2]의 Git [4]으로 Python의 개발 프로세스를 마이그레이션하는 데 필요한 단계를 설명합니다. 이 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. 병합 경쟁을 피하기 위해 변경 사항을 가져옵니다.
  10. 변경 사항을 수동으로 커밋합니다.
  11. 변경 사항이 버그 수정 릴리스에 해당하면 개발 중인 브랜치에 병합합니다.
  12. 테스트 모음을 다시 수동으로 실행합니다.
  13. 병합을 커밋합니다.
  14. 변경 사항을 푸시합니다.

이는 핵심 개발자에게 매우 무겁고 수동적인 프로세스입니다. 간단한 경우에도 코드 검토 단계만 건너뛸 수 있을 뿐이며, 여전히 문서를 빌드해야 합니다. 그 결과 핵심 개발자가 제출물을 따라잡을 만큼 빠르게 밀린 작업을 처리하지 못하여 패치가 이슈 추적 시스템에 방치되었습니다. 이는 다시 관심을 받지 못해 좌절한 외부 기여자들이 기여를 꺼리게 되는 부수적인 문제로 이어졌으며, 실행 가능한 프로젝트의 미래를 확보하는 데 역행하므로 기업의 지원이 없는 오픈 소스 프로젝트에는 위험한 문제입니다. 외부 기여자가 bugs.python.org [5]에 패치를 업로드하는 것은 잠재적으로 간단하지만, 핵심 개발자가 이를 처리하기에는 그만큼 느리고 부담스럽습니다.

따라서 2014년 말에 새로운 개발 프로세스로의 전환이 필요하다는 결정이 내려졌습니다. 새로운 워크플로를 제안하는 PEP를 요청했으며, 결국 GitHub [2]와 GitLab [7]을 각각 제안하는 두 개의 PEP, PEP 481 및 PEP 507로 이어졌습니다.

2015년에는 간헐적으로 이러한 제안들을 작업하고, core-workflow 메일링 리스트 [8]에서 무엇이 서로 다른지에 대한 세부 사항을 도출하려고 노력했습니다. PyCon US 2015에서도 신규 기여자에게 요구되는 인지적 부담과 핵심 개발자가 패치를 검토하는 데 걸리는 시간이 모두 문제였기 때문에 커뮤니티가 우리 프로세스에 다소 불만을 느끼고 있다는 점이 드러났습니다(이러한 좌절의 사례로 PyCon US 2015에서 Guido van Rossum의 기조연설 마지막 부분 [9]을 참조하십시오).

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

  • 사용자 지정 인프라를 유지 관리하는 일은 자원봉사자들에게 부담이 되어 왔습니다(예를 들어, 현재 유지 관리되지 않는 Rietveld의 사용자 지정 포크 [6]가 사용되고 있습니다).
  • 사용자 지정 워크플로는 핵심 개발자들에게 매우 많은 시간이 소요됩니다(이를 지원하는 자동화 도구가 충분히 구축되어 있지 않습니다).
  • 사용자 지정 워크플로는 외부 기여자들에게 방해 요소가 됩니다(CPython 자체에 고유한 개발 프로세스를 익히는 데 필요한 시간 때문에 진입 장벽으로 작용합니다).
  • GitLab이 오픈 소스라는 점 외에는 GitLab과 GitHub를 구별하는 기능이 없습니다.
  • 핵심 개발자와 외부 기여자 사이에서 GitHub에 대한 친숙도는 GitLab에 대한 친숙도보다 훨씬 높습니다.
  • 우리 BDFL은 GitHub를 선호합니다(자신의 의견은 중요하지 않아야 한다고 여러분에게 가장 먼저 말할 사람이겠지만, 결정을 내린 사람은 BDFL이 자신이 만든 프로그래밍 언어의 워크플로를 편안하게 느끼는 것이 지속적인 참여를 독려하는 데 중요하다고 생각했습니다).

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

이번 이전의 궁극적인 목표는 핵심 개발자가 WiFi를 사용하는 태블릿의 브라우저에서 some 개발 프로세스를 통해 외부 기여 제출부터 해당 기여를 커밋하는 데 이르는 모든 단계를 진행할 수 있을 정도로 개발 프로세스를 개선하는 것입니다(이것이 본질적으로 GitHub의 기본 워크플로를 의미하는 것은 아닙니다). 최종 해결책은 외부 기여자가 GitHub를 사용하지 않기로 선택한 경우에도 기여할 수 있도록 합니다(다만 기능 동등성이 보장되지는 않습니다).

이전할 저장소

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

  1. devinabox [12] (완료)
  2. benchmarks [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 조직의 일부로 ‘Python core’ 팀이 생성됩니다 [16]. 이전되는 모든 저장소에는 쓰기 권한과 함께 ‘Python core’ 팀이 추가됩니다 [17]. 이전에 hg.python.org에서 SSH 키를 관리할 권한이 있었던 사람은 누구나 ‘Python core’ 팀의 팀 관리자(maintainer)가 됩니다.

Mercurial 저장소를 Git으로 이전하는 명령 정의

GitHub로 이동하면 Git [4]로도 이동하게 되므로, Mercurial 저장소를 Git으로 변환하기 위해 실행할 도구와 명령을 결정해야 합니다. 이 마이그레이션을 위해 특별히 개발된 도구는 https://github.com/orsenthil/cpython-hg-to-git 에 호스팅되어 있습니다.

CLA 시행

모든 오픈 소스 프로젝트의 핵심적인 부분은 소스 코드에 적절한 라이선스를 적용할 수 있도록 하는 것입니다. 이를 위해 기여하는 모든 사람이 기여자 라이선스 계약(CLA) [18] 에 서명했는지 확인해야 합니다. 지금까지 기여된 코드에 대한 CLA 서명 시행은 핵심 개발자가 bugs.python.org [5] 에서 사용자 이름 옆에 *가 있는지 확인하는 방식으로 이루어졌습니다. 이번 마이그레이션에서는 기여자의 CLA 서명 여부를 자동으로 확인하고 시행하는 것부터 시작할 계획입니다.

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

PSF의 직접적인 관리 아래 CLA 서명 추적을 유지하기 위해, 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 요청을 보내면, 요청한 사용자 이름을 키로 하고 CLA에 서명했으면 true, 서명하지 않았으면 false, 해당하는 GitHub 사용자 이름을 찾지 못했으면 null을 값으로 갖는 JSON 딕셔너리가 반환됩니다.

CLA 서명을 시행하는 봇

누군가의 GitHub 계정과, 해당 사용자가 CLA에 서명했는지에 대한 데이터를 보유한 bugs.python.org [5] 계정 사이의 연결을 바탕으로, 봇은 GitHub의 풀 리퀘스트를 모니터링하고 기여자가 CLA에 서명했는지 표시할 수 있습니다.

사용자가 CLA에 서명했다면 봇은 풀 리퀘스트에 CLA 문제가 없음을 나타내는 긍정적인 레이블을 이슈에 추가합니다(예: “CLA signed”라고 표시된 녹색 레이블). 기여자가 CLA에 서명하지 않았다면 부정적인 레이블이 풀 리퀘스트에 추가되고 GitHub의 상태 API를 사용하여 차단됩니다(예: “CLA not signed”라고 표시된 빨간색 레이블). 기여자에게 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] 입니다. 중요성과 높은 사용 빈도로 인해 이 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 해시로 간주됩니다.

bugs.python.org commit number rewriter도 7자리만큼 짧은 해시를 허용하도록 업데이트해야 합니다. Git은 그 정도로 짧거나 더 긴 해시와 일치하기 때문입니다.

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를 통해 생성된 커밋의 경우 파일 생성을 지원하는 스크립트를 제공할 수 있습니다. 봇 기반 시나리오에서는 병합 봇이 특정 뉴스 항목을 지정하고 이를 플랫화된 커밋의 일부로 파일에 생성할 수 있습니다. 특정 뉴스 항목이 지정되지 않은 경우에는 커밋 메시지의 첫 번째 줄을 사용하는 기능도 지원할 가능성이 높습니다. 웹 기반 워크플로를 사용하는 경우 상태 확인을 통해 풀 리퀘스트에 새 항목 파일이 있는지 검증하여 파일이 누락되었음을 알리는 역할을 하게 할 수 있습니다. 이 접근 방식의 코드는 이전에 http://bugs.python.org/issue18967 에서 Mercurial 워크플로용으로 작성되었습니다. 또한 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은 커밋마다 author 값과 committer 값을 모두 지원하므로, 커밋의 작성자 정보가 코드 자체의 이력에 포함될 수 있습니다.

따라서 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]를 코드 호스팅 및 코드 리뷰에 사용하게 되므로, 이 두 가지를 백업해야 합니다. 코드 호스팅의 경우 모든 얕지 않은 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]의 이슈에 알림을 보내는 과정이 포함되어 있지 않습니다. 사람들이 bugs.python.org의 댓글만 구독하고 GitHub [2]는 구독하지 않으면서도 관련 풀 리퀘스트의 리뷰 댓글과 관련하여 GitHub에서 무슨 일이 발생하는지 알 수 있도록 이를 수정하면 좋겠습니다. 현재로서는 일정 기간(예: 15분 또는 30분) 동안 리뷰 댓글이 하나 이상 작성되었을 때 bugs.python.org의 관련 이슈에 댓글을 게시하는 방안이 고려되고 있습니다. 하지만 GitHub가 이제 reviews 를 지원하므로 시간 요소는 불필요할 수도 있습니다. 이렇게 하면 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 커밋의 커미터 필드가 올바르게 채워져 있기만 하다면 이 작업에는 반드시 GitHub 통합이 필요한 것도 아닙니다.

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

상태

devinabox [12] 저장소를 마이그레이션하기 위한 요구 사항:

빌드 단계를 업데이트해야 하는 저장소:

cpython repo [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이 여러 봇의 최종 이름을 선택합니다(봇 자체에 사용되는 프로젝트의 이름은 무엇이든 될 수 있으며, 이는 봇에 명령을 내릴 때 사용되는 이름이나 계정 이름만을 위한 것입니다). Python이 해당 코미디 극단의 이름을 따서 지어졌으므로, 이름은 Monty 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로 돌아가 뉴스 항목을 추가해야 한다는 점을 기억해야 함을 의미합니다.

참조 자료입니다.