PEP 581 – CPython에 GitHub Issues 사용하기

Author:: Mariatta <mariatta at python.org>
BDFL-Delegate:: Barry Warsaw <barry at python.org>
Discussions-To:: Discourse thread
Status:: Final
Type:: Process
Created:: 20-Jun-2018
Post-History:: 07-Mar-2019
Resolution:: Python-Dev message

Table of Contents

초록
근거
- 왜 GitHub인가?
- Roundup / bpo의 문제점
GitLab을 사용하지 않는 이유는 무엇입니까?
다른 이슈 추적기를 사용하지 않는 이유는 무엇입니까?
Roundup / bpo 개선에 집중하는 것은 어떻습니까?
GitHub의 단점
추가 질문 및 논의
감사의 말
참고 자료
Copyright

번역·라이선스 안내

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

초록

이 PEP는 Python의 Roundup 이슈 추적기에서 GitHub Issues로 마이그레이션하는 근거를 설명합니다. 자세한 마이그레이션 계획은 PEP 588을 참조하십시오.

근거

CPython의 개발은 2017년 2월에 GitHub로 이전했습니다. PSF 조직 내의 다른 모든 프로젝트는 GitHub에서 호스팅되며 GitHub Issues를 사용하고 있습니다. CPython은 여전히 bugs.python.org (bpo)에서 Roundup을 이슈 추적기로 사용하고 있습니다 [1].

왜 GitHub인가?

GitHub에는 즉시 사용할 수 있는 유용한 기능이 많이 있습니다. 이러한 기능 중 일부는 Roundup / bpo에서 즉시 사용할 수 없습니다.

통합과 자동화를 구축하는 데 사용할 수 있는 API가 제공됩니다. 워크플로를 지원하는 다양한 기존 통합 및 애플리케이션을 GitHub Marketplace에서 사용할 수 있습니다. 새로운 애플리케이션은 쉽게 설치하고 활성화할 수 있습니다. 또한 miss-islington [2], bedevere [3], the-knights-who-say-ni [4]와 같은 자체 GitHub 봇을 구축하여 큰 성공을 거두었습니다.
스크린샷과 디버그 로그 파일을 GitHub 풀 리퀘스트와 이슈에 삽입하거나 끌어다 놓을 수 있습니다.
관리자와 핵심 개발자는 이슈, 댓글 및 풀 리퀘스트를 편집할 수 있습니다.
이메일을 통해 이슈 및 풀 리퀘스트 대화에 답장할 수 있습니다.
이중 인증을 지원합니다.
Markdown과 이모지를 지원합니다.
댓글을 실제로 게시하기 전에 댓글이 어떻게 렌더링될지 보여 주는 미리 보기 탭이 제공됩니다.
리액션을 통한 투표를 지원합니다.
퍼머링크 [5]를 지원하므로 소스 코드를 쉽게 인용하고 복사하여 붙여 넣을 수 있습니다. 퍼머링크를 붙여 넣으면 GitHub에서 코드 조각을 자동으로 삽입할 수 있습니다.
핵심 개발자, 자원봉사자 및 PSF는 이슈 인프라와 사이트를 유지 관리할 필요가 없으므로 Python 개발에 집중할 시간과 리소스를 더 많이 확보할 수 있습니다.
PR이 병합되면 이슈를 자동으로 닫을 수 있습니다 [6].
- 이 기능은 bpo에도 존재한다는 점에 유의하십시오.
기여에 대한 진입 장벽이 낮아집니다. 사용자가 2,800만 명 이상이므로 오픈 소스 기여자는 이미 계정을 보유하고 GitHub 인터페이스에 익숙할 가능성이 높아 기여를 시작하기가 더 쉬워집니다.
메타데이터가 포함된 이메일 알림 [7]이 Gmail과 통합되어 이메일을 체계적으로 필터링할 수 있습니다. Roundup 이메일에도 일부 메타데이터가 포함되어 있지만 그 정도가 광범위하지는 않습니다.
사용자가 이메일 주소를 숨길지 선택할 수 있도록 하는 등 추가적인 개인정보 보호 기능을 제공하면서도 @-멘션을 통해 사용자와 계속 소통할 수 있습니다.

Roundup / bpo의 문제점

5명 미만의 사람들이 bpo를 유지 관리합니다. 그중 일부는 핵심 개발자입니다.
업스트림 Roundup 코드는 Mercurial에 있습니다. CI를 사용할 수 없으므로, 기존의 소수 유지 관리자에게 패치를 검토하고 테스트하고 적용하는 측면에서 큰 부담이 됩니다. GitHub에 Roundup의 비공식 미러 [8]가 있지만, Mercurial 패치가 여전히 이에 기여하는 주요 방법입니다.
bpo의 소스 코드를 GitHub로 옮기는 것에 관한 논의가 진행 중입니다 [9]. bpo의 소스 코드가 GitHub로 옮겨지면 업스트림의 패치를 업데이트하기가 어려워집니다. 그러나 Mercurial에 있는 한 유지 관리와 새로운 기여자의 온보딩이 어렵습니다.
현재 상태의 프로젝트는 코드베이스에 이미 익숙하지 않은 사람들의 많은 기여를 받아들일 준비가 되어 있지 않습니다.
사용자 인터페이스를 업데이트하고 다시 설계해야 합니다. 접근성을 포함한 최신 웹 표준에 맞게 유지하려면 UX/UI 연구가 필요합니다.
사용자의 이메일 주소가 노출되었습니다.
- 참고: 등록하고 로그인한 사용자에게 이메일 주소를 노출하는 것은 bpo 인스턴스를 설정할 때 내린 결정이었습니다. 이 동작은 PEP 581이 승인된 후 최근에 수정되었습니다.
현재 bpo에서는 REST API를 사용할 수 없습니다. Roundup에는 REST API를 추가하기 위한 미해결 이슈가 있었습니다 [10]. 당시 PEP 581이 제안되었을 때, 해당 티켓에는 2016년 이후 아무런 활동도 없었습니다. REST API는 2019년 2월에 Roundup에 통합되었지만, 아직 bpo에는 통합되지 않았습니다.
불필요한 이메일과 알림을 여러 건 보냅니다. 한 가지 예로 nosy 이메일이 있으며, 누군가 자신을 “nosy”로 추가할 때마다 이메일 알림이 전송됩니다. 이 문제에 관한 이슈가 2012년부터 업스트림 Roundup에 등록되어 있지만 진전은 거의 없었습니다 [11]. 구성할 수는 있지만, 이를 구성해 달라는 요청은 처리되지 않거나 무시되었습니다.
계정을 만드는 일은 번거로웠습니다. 계정을 만들거나 로그인하는 데 어려움을 겪었다는 보고가 있었습니다. 미해결 티켓의 예로는 “Commas in username causes error in nosy list” [12], “An error has occurred ..” [13], “It is not sending me the confirmation email …” [14] 등이 있습니다.

GitLab을 사용하지 않는 이유는 무엇입니까?

2017년에 GitHub 대신 GitLab으로 이전했다면 이 PEP의 제목은 “Using GitLab Issues for CPython”이 되었을 것입니다.

다른 이슈 추적기를 사용하지 않는 이유는 무엇입니까?

다른 이슈 추적기를 사용하면 서로 다른 인터페이스를 배우고 익혀야 하므로 또 다른 학습 곡선이 필요합니다. 또한 GitHub와의 통합을 구축하는 방법을 배우고 파악해야 합니다.

현재 CPython 소스 코드가 호스팅되고 풀 리퀘스트가 이루어지는 GitHub 이슈를 사용하면, 한 인터페이스에서 다른 인터페이스로 이동할 필요 없이 기여자와 유지 관리자에게 일관된 경험을 제공할 수 있습니다.

Roundup / bpo 개선에 집중하는 것은 어떻습니까?

GitHub에는 이미 제공되는 유용한 기능이 많이 있습니다. 여전히 추가 통합 기능을 구축하고 봇을 업데이트해야 하지만, 이는 이미 수행 방법을 알고 있는 작업입니다.

Roundup / bpo를 실제로 개선하려면 먼저 GitHub로 마이그레이션하고 CI와 봇을 추가해야 합니다. 제가 이해하기로는 업스트림 Roundup이 아직 Mercurial을 사용하고 있기 때문에 망설임이 있습니다. Roundup / bpo에 더 익숙한 누군가가 이 작업에 앞장서야 합니다. (제가 자원하는 것은 아닙니다. 죄송합니다.)

GitHub 통합 기능과 봇을 만들고 유지 관리하는 데 드는 노력은 Roundup을 최신 상태로 정비한 다음 계속 유지 관리하는 데 필요한 노력보다 훨씬 적다고 생각합니다.

GitHub의 단점

GitHub는 완벽한 이슈 추적기가 아닙니다. 우리가 인지해야 할 몇 가지 문제가 있습니다:

불확실성과 공급업체 종속에 대한 두려움입니다. GitHub는 독점적이며 공급업체 종속의 위험이 있습니다. 그러나 CPython의 코드베이스가 이미 GitHub에 있으므로 이는 기존 문제입니다. 이는 CPython에만 고유한 문제도 아닙니다. 예방 조치로 CPython의 GitHub 저장소는 2018년 6월부터 매일 백업되어 왔습니다. [15]
봇 유지 관리에는 비용이 들며 자원봉사자의 시간도 소요됩니다. 유지 관리 부담을 Roundup에서 봇으로 옮기게 됩니다. 적어도 지금까지는 봇/GitHub API와 관련된 버그나 문제를 수개월 또는 수년이 아니라 며칠 내로 상당히 신속하게 해결할 수 있었습니다. GitHub API는 광범위하며 CPython의 봇뿐만 아니라 더 넓은 Python 커뮤니티에서도 사용됩니다. 따라서 Roundup/bpo 유지 관리에 비해 GitHub API에 더 쉽게 접근할 수 있습니다.
GitHub를 사용하면 이슈 분류에 필요한 노력이 늘어날 가능성이 있습니다. 이는 처음에 Zulip 주제로 제기되었고 [16], 2018년 9월 Core Python 스프린트 중에도 제기되었습니다 [17]. 특별한 이슈 분류 팀을 만드는 것과 같은 몇 가지 해결책이 제안되고 검토되었습니다 [18]. 승인된 후, PEP 581은 GitHub가 현재 베타 단계인 새로운 트리아지 역할을 출시했습니다. PSF는 Python 조직에서 이를 활성화하기 위해 GitHub와 연락해 왔습니다. 이는 GitHub의 검토를 기다리는 중입니다 [19].
GitHub를 사용하면 사람들이 방해가 되거나 스팸성인 댓글을 더 쉽게 게시할 수 있습니다. 핵심 개발자가 GitHub에서 방해가 되는 토론을 중재하고 잠가야 했던 사건들이 있었던 것은 사실입니다. 다행히 GitHub 인터페이스를 사용하면 핵심 개발자가 토론을 쉽게 중재할 수 있습니다. 또한 사건을 GitHub에 에스컬레이션할 수 있습니다.
이슈 템플릿을 수동으로 편집하는 작업은 번거롭고 오류가 발생하기 쉽습니다. 그러나 대부분의 사람에게는 bpo에서 이슈를 생성하는 것보다 GitHub에서 이슈를 생성하는 것이 훨씬 더 나은 경험이 될 것입니다. 선택해야 할 필드와 텍스트 상자가 매우 많아 처음 사용하는 사람에게 혼란스럽고 부담스러울 수 있으며, 메시지를 “편집”할 수 없습니다. GitHub에서는 이슈 작성자가 제출 내용을 미리 보고 게시한 후 실수를 수정할 수 있습니다.
bpo는 여러 메타데이터를 지정하기 위해 여러 필드를 사용하며, 이러한 필드는 GitHub로 쉽게 이전되지 않을 수 있습니다. GitHub에서 사용자 지정 메타데이터를 처리하는 의도된 방법은 레이블을 사용하는 것입니다. 생성할 레이블에 관한 자세한 내용은 PEP 588에서 추가로 논의합니다.