PEP 588 – GitHub 이슈 마이그레이션 계획
- Author:
- Mariatta <mariatta at python.org>
- BDFL-Delegate:
- Barry Warsaw <barry at python.org>
- Discussions-To:
- Discourse thread
- Status:
- Final
- Type:
- Informational
- Created:
- 27-Mar-2019
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 Roundup 기반의 Python 이슈 트래커에서 GitHub 이슈로 마이그레이션하기 위한 세부 계획을 설명합니다. 근거와 배경은 PEP 581을 참조하십시오. PEP 588에도 마이그레이션의 세부 일정이 설명되어 있습니다.
마이그레이션 계획
여기에서는 CPython 개발자의 생산성에 미치는 영향을 최소화하면서 버그 추적을 GitHub로 마이그레이션하기 위해 수행해야 할 작업과 단계, 그리고 내려야 할 핵심 결정 사항을 개괄합니다.
전문 프로젝트 관리자 고용
Warehouse 프로젝트가 관리된 방식과 마찬가지로, 마이그레이션을 담당할 전문 프로젝트 관리자를 두면 이 프로젝트의 성공을 보장하는 데 도움이 될 것입니다.
GitHub에 CPython 시험용 이슈 트래커 만들기
새로운 워크플로를 실험하고 시험해 볼 수 있는 시험용 이슈 트래커를 GitHub에 만들어야 합니다.
GitHub 데이터 백업
이 작업은 이미 시작되었으며, core-workflow(코어 워크플로) 저장소의 이슈로 추적되고 있습니다 [1]. GitHub의 Migrations API [2]를 사용하여 CPython의 GitHub 데이터를 매일 내려받고 있습니다. 아카이브는 S3 버킷에 저장될 것입니다.
이 작업을 맡아 준 Ee Durbin에게 감사드립니다.
CLA 호스트 변경
현재 CLA는 bpo 내부에서 호스팅되고 있습니다. CLA에 서명할 때 bpo 계정이 필요하지 않도록 변경해야 하며, CLA는 bpo 외부에서 호스팅되어야 합니다.
현재의 CLA 절차 자체도 이상적이지 않습니다. 현재 devguide, peps, core-workflow(코어 워크플로) 저장소의 기여자는 CLA에 서명해야 하며, 이를 위해서는 bpo 계정이 필요합니다. 이들 프로젝트에 bpo 계정이 필요해서는 안 됩니다.
현재 시행 중인 CLA 절차 대신 자체 CLA assistant 인스턴스를 사용하기 위한 작업이 진행 중입니다. 이에 관한 논의가 core-workflow 메일링 리스트와 Discourse에서 시작되었습니다.
cla-assistant가 아직 조직을 대표하여 서명한 CLA를 지원하지 않기 때문에 이 작업은 현재 중단된 상태입니다.
GitHub에 “Python Triage” 팀 만들기
bpo의 버그 트리아지 담당자들은 핵심 Python 워크플로에 매우 소중한 존재이며, GitHub에서 이슈를 트리아지하는 데에는 분명히 더 많은 도움이 필요할 것입니다.
이슈를 닫고, 적절한 당사자에게 알리고, 이슈와 풀 리퀘스트에 레이블을 붙이는 일을 돕기 위해 GitHub에 “버그 분류(bug triage)” 팀을 만들자는 의견이 Discourse에서 제안되었습니다.
GitHub의 새로운 Triage 역할은 현재 베타 단계이며, Python 조직은 이 역할에 대한 접근 권한을 부여받았으므로 이를 활용하기 시작할 수 있습니다.
“Python Triage” 팀이 만들어졌습니다. 트리아지 역할에 대한 설명과 기대 사항이 Devguide에 추가되었습니다.
이 프로젝트의 진행 상황은 “Adding Triagers” 프로젝트 보드에서 확인할 수 있습니다.
이슈 분류를 위한 레이블 생성
현재 bpo에서는 각 이슈에 다음 필드가 있습니다.
유형: behavior, crash, compile error, resource usage, security, performance, enhancement.
구성 요소: 2to3, Argument Clinic, asyncio, Build, Cross-build, ctypes, …
우선순위: release blocker, deferred blocker, critical, high, normal, low
이에 대응하는 레이블을 만들겠습니다.:
type-behavior, type-crash, type-compile error, type-resource usage, ...
components-2to3, components-argument clinic, components-asyncio, ...
priority-release blocker, priority-deferred blocker, priority-critical, ...
또한 needs triage 레이블도 만들겠습니다.
최종적으로 만들 “레이블”은 나중에 GitHub 이슈로 전환을 시작할 때 결정할 수 있습니다.
가능한 모든 레이블과 색상 스키마를 담은 테스트 저장소를 Carol Willing이 만들었으며, https://github.com/willingc/test-581/labels 에서 검토할 수 있습니다.
이슈 템플릿 생성
이슈 템플릿을 만들고 다음 헤더를 추가하겠습니다.:
---
Type: behavior | crash | compile error | resource usage (choose one)
Components: 2to3 | Argument Clinic | asyncio | Build | ... (can select more than one)
Priority: release blocker | deferred blocker | critical | ...
Needs backport to: 2.7 | 3.6 | 3.7
---
이슈 작성자가 이슈 분류를 도울 수 있게 하려는 것입니다. 위의 값들은 템플릿에 미리 채워져 있습니다. 이슈 작성자는 자신의 이슈에 해당하지 않는 텍스트를 삭제합니다.
위의 헤더를 바탕으로 bedevere-bot이 이슈에 필요한 레이블을 붙일 수 있습니다. 이슈 작성자가 위의 헤더를 제공하지 않으면 봇이 needs triage 레이블을 붙입니다. 그 시점에서는 코어 개발자가 이슈에 레이블을 적절히 붙여야 합니다.
또한 GitHub의 다중 이슈 템플릿 기능과, 이슈 템플릿을 사용해 이슈 담당자와 레이블을 자동으로 지정하는 기능을 활용할 수 있습니다.
bedevere 업데이트
Bedevere-bot이 위에서 설명한 이슈 헤더를 인식하고 적절한 레이블을 붙이도록 업데이트해야 합니다.
Bedevere-bot은 해당 이슈에 대응하는 풀 리퀘스트에 레이블을 복사할 수도 있습니다.
devguide 업데이트
Devguide에 GitHub 이슈를 사용하는 새 워크플로에 관한 정보를 추가해야 합니다. 이 작업은 별도 브랜치에서 진행할 수 있으며, 마이그레이션 이후가 아니라 그 전에 완료해야 합니다.
bpo에 이슈를 GitHub로 마이그레이션하는 버튼 추가
이를 위해서는 bpo를 업데이트해야 합니다. 하지만 이에 필요한 노력은 전면 개편보다 훨씬 적다고 생각합니다.
bpo에 이슈 설명과 관련 댓글을 GitHub 이슈로 복사하는 버튼을 만들겠습니다.
GitHub 이슈의 URL과 함께 “moved”라는 새 상태를 추가해야 합니다.
열려 있는 모든 이슈를 GitHub로 옮겨서는 안 됩니다. 누군가 해당 이슈에 대한 작업이나 논의를 계속하는 데 관심이 있을 때에만 이슈를 GitHub로 “옮겨야” 합니다.
마이그레이션된 이슈
이슈가 “moved”로 표시되면 해당 이슈는 읽기 전용 모드여야 합니다. bpo는 해당 이슈의 편집을 금지해야 합니다.
bpo를 읽기 전용으로 전환
이는 마지막 단계여야 합니다. GitHub 이슈를 사용하기 시작하면 bpo를 폐쇄하는 대신 읽기 전용으로 전환하십시오. 새 가입을 받지 마십시오. 댓글이나 이슈를 생성할 수 없게 하십시오.
bpo와 GitHub 간 이슈 매핑
보통 bpo의 이슈를 참조할 때는 bpo-XYZ를 사용하지만, GitHub에서는 https://github.com/python/cpython/issue/XYZ 형식의 새로운 참조를 사용하게 됩니다.
이슈를 bpo에서 GitHub로 이전할 것이므로, bpo에는 GitHub 이슈를 참조하기 위한 새 필드가 필요하고, GitHub에도 마찬가지로 bpo로부터의 ‘최종’ 참조를 위한 필드가 필요합니다.
GitHub에는 origin: https://bugs.python.org/issueXYZ를 추가해야 합니다. bpo에는 새 필드 moved to: https://github.com/python/cpython/issue/XYZ를 추가하십시오.
전문가를 nosy 목록에 추가하기
현재 bpo에는 특정 분야의 전문가로 등록된 사람들을 자동으로 nosy 목록에 추가하는 기능이 있습니다. 여러 Python 코어 개발자는 GitHub의 모든 것을 구독하기보다는 자신의 관심 분야와 전문 분야에 관련된 이슈에 대해서만 알림을 받는 편을 선호한다고 밝혔습니다.
이러한 상황에 도움이 되도록, 이슈가 레이블로 분류될 때마다 사람들에게 알림을 보내는 봇을 개발할 수 있습니다. 예를 들어 이슈에 area-windows 레이블이 붙으면 Windows 전문가들에게 알림을 보낼 수 있습니다. 알림은 이메일 알림이나 GitHub의 @-멘션 형태가 될 수 있습니다.
미해결 문제
GitHub 계정이 필수 요건이 되어서는 안 됩니다
CPython 코드베이스를 Mercurial에서 GitHub로 옮기는 방안이 논의되던 당시 [3] [4], 여전히 bpo에 패치를 업로드할 수 있어야 하며 Python에 기여하는 데 GitHub 계정이 필수 요건이 되어서는 안 된다는 의견이 제기되었습니다.
bpo가 읽기 전용이 되면, GitHub 계정이 없는 사람도 기여할 수 있도록 하는 다른 해결책을 마련해야 합니다.
한 가지 해결책은 docs@python.org [5] 메일링 리스트와 비슷한 새 “python-issues” 메일링 리스트를 만들어 사람들이 그곳에 이슈를 제출할 수 있게 하는 것입니다.
이와 관련하여, 2017년 GitHub로 이전한 이후 Mercurial에 패치를 제출하고 GitHub 계정 생성을 거부한 기여자가 있었던 사례 [6] 하나를 기억합니다. 이 때문에 우리 봇은 그 기여자가 CLA에 서명했는지 감지할 수 없었습니다. 다른 사람이 그 패치를 GitHub에 업로드하겠다고 자원했습니다. 하지만 여전히 두 사람 모두 CLA에 서명해야 했습니다.
그 상황은 특히 복잡했습니다. CLA를 조사하고 수동으로 확인하는 데 코어 개발자 다섯 명의 시간이 들었으며, 혼란을 초래했습니다.
“Components” 목록 줄이기
현재의 “components” 목록이 여전히 타당하고 적절합니까? 목록을 줄일 수 있습니까?
우선순위 목록
현재의 “우선순위” 목록은 유용합니까? Alyssa Coghlan은 아마도 release blocker와 deferred blocker만 유용할 것이라고 언급했습니다.
추가 질문 및 논의
질문은 Discourse의 Core-Workflow 카테고리에 올릴 수 있습니다.
감사의 글
이 PEP의 초기 단계와 조사 과정에서 자문해 주신 Guido van Rossum, Brett Cannon, Alyssa Coghlan께 감사드립니다. 이분들의 피드백, 우려, 의견, 아이디어는 매우 귀중했습니다.
참고 문헌
Copyright
This document has been placed in the public domain.