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는 Python의 Roundup 이슈 추적기에서 GitHub 이슈로 마이그레이션하기 위한 세부 계획을 설명합니다. 근거와 배경은 PEP 581을 참조하십시오. PEP 588에도 마이그레이션의 세부 일정이 설명되어 있습니다.
마이그레이션 계획
여기에서는 CPython 개발자의 생산성에 미치는 영향을 최소화하면서 버그 추적을 GitHub로 마이그레이션하기 위해 수행해야 할 작업, 단계 및 핵심 결정을 개괄합니다.
전문 프로젝트 관리자 고용
Warehouse 프로젝트가 관리된 방식과 유사하게 마이그레이션을 담당할 전문 프로젝트 관리자를 두면 이 프로젝트의 성공을 보장하는 데 도움이 될 것입니다.
GitHub에 플레이그라운드 CPython 이슈 추적기 만들기
새로운 워크플로를 실험하고 테스트할 수 있는 플레이그라운드 이슈 추적기를 GitHub에 만들어야 합니다.
GitHub 데이터 백업
이 작업은 시작되었으며 core-workflow [1]의 이슈로 추적되고 있습니다. CPython의 GitHub 데이터를 매일 다운로드하기 위해 GitHub의 Migrations API [2]를 사용하고 있습니다. 아카이브는 S3 버킷에 저장됩니다.
이 작업을 진행해 주신 Ee Durbin님께 감사드립니다.
CLA 호스트 업데이트
현재 CLA는 bpo 내부에서 호스팅되고 있습니다. CLA에 서명하는 데 bpo 계정이 필요하지 않도록 업데이트해야 하며, bpo 외부에서 호스팅되어야 합니다.
현재 CLA 프로세스 자체는 이상적이지 않습니다. 현재 devguide, peps 및 core-workflow의 기여자는 CLA에 서명해야 하며, 이를 위해 bpo 계정이 필요합니다. 이러한 프로젝트에는 bpo 계정이 필요하지 않아야 합니다.
현재 사용 중인 CLA 프로세스 대신 자체 CLA assistant 인스턴스를 사용하기 시작하려는 작업이 진행 중입니다. 이에 대한 논의는 core-workflow mailing list 및 Discourse에서 시작되었습니다.
cla-assistant가 아직 조직을 대신하여 서명된 CLA를 지원하지 않기 때문에 이 작업은 현재 is currently stalled 상태입니다.
GitHub에 “Python Triage” 팀 만들기
bpo의 버그 트리아지 담당자는 핵심 Python 워크플로에 매우 중요하며, GitHub에서 이슈를 트리아지하는 데에는 분명히 더 많은 도움이 필요합니다.
이슈를 종료하고, 적절한 당사자에게 알리며, 이슈와 풀 리퀘스트에 레이블을 적용하는 데 도움을 줄 “bug triage” 팀을 GitHub에 만들자는 제안이 proposed on Discourse에 제시되었습니다.
GitHub의 새로운 Triage 역할은 현재 베타 단계이며, Python 조직은 이 역할에 대한 액세스 권한을 부여받았으므로 이를 활용하기 시작할 수 있습니다.
“Python Triage” 팀이 만들어졌습니다. 트리아지 역할에 대한 설명과 기대 사항이 have been added to Devguide에 추가되었습니다.
이 프로젝트의 진행 상황은 “Adding Triagers” project board에서 추적할 수 있습니다.
이슈 분류를 위한 레이블을 생성하십시오.
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”해야 합니다.
마이그레이션된 이슈
이슈가 “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의 @-mention 형식으로 보낼 수 있습니다.
미해결 이슈
GitHub 계정이 필수 조건이어서는 안 됩니다.
Mercurial에서 GitHub로 CPython 코드베이스를 이전하는 방안이 논의되던 당시 [3] [4], bpo에서 패치를 계속 업로드할 수 있어야 하며 Python에 기여하기 위해 GitHub 계정이 필수 조건이어서는 안 된다는 의견이 제기되었습니다.
bpo를 읽기 전용으로 전환하면 GitHub 계정이 없는 사람들이 기여할 수 있도록 다른 해결책을 마련해야 합니다.
한 가지 해결책은 docs@python.org [5] 메일링 리스트와 유사한 새 “python-issues” 메일링 리스트를 만들어 사람들이 그곳에 이슈를 제출할 수 있도록 하는 것입니다.
이와 관련하여, 2017년 GitHub로 마이그레이션한 이후 [6] Mercurial에 패치를 제출했지만 GitHub 계정을 만들기를 거부한 기여자가 있었던 한 사례가 기억납니다. 이 때문에 봇이 해당 기여자가 CLA에 서명했는지 확인할 수 없었습니다. 다른 사람이 해당 패치를 GitHub에 업로드하겠다고 자원했습니다. 그러나 두 사람 모두 CLA에 서명해야 했습니다.
해당 상황은 복잡했습니다. CLA를 조사하고 수동으로 확인하는 데 핵심 개발자 5명의 시간이 소요되어 혼란이 발생했습니다.
“Components” 목록 축소
현재 “components” 목록이 여전히 의미 있고 관련성이 있습니까? 목록을 줄일 수 있습니까?
우선순위 목록
현재 “priority” 목록은 유용합니까? 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.