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

Python 개선 제안 한국어 번역

PEP 581 – CPython에서 GitHub 이슈 사용하기

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

번역·라이선스 안내

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

초록

이 PEP는 Roundup 기반의 Python 이슈 트래커에서 GitHub 이슈로 이전하는 근거를 설명합니다. 자세한 이전 계획은 PEP 588을 참고하십시오.

근거

CPython 개발은 2017년 2월에 GitHub로 옮겨 갔습니다. PSF 조직의 다른 모든 프로젝트는 GitHub에 호스팅되어 있으며 GitHub 이슈를 사용하고 있습니다. 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 풀 리퀘스트와 이슈에 스크린숏과 디버그 로그 파일을 삽입하거나 끌어다 놓을 수 있습니다.
  • 관리자와 코어 개발자는 이슈, 댓글, 풀 리퀘스트를 편집할 수 있습니다.
  • 이슈와 풀 리퀘스트 대화에 이메일로 답장할 수 있습니다.
  • 2단계 인증을 지원합니다.
  • 마크다운과 이모지를 지원합니다.
  • 댓글을 실제로 게시하기 전에 어떻게 렌더링될지 보여 주는 미리 보기 탭이 있습니다.
  • 리액션을 통한 투표를 지원합니다.
  • 퍼머링크 [5]를 지원하므로 소스 코드를 쉽게 인용하고 복사해 붙여 넣을 수 있습니다. 퍼머링크를 붙여 넣으면 GitHub에서 코드 조각을 자동으로 삽입할 수 있습니다.
  • 코어 개발자와 자원봉사자, PSF가 이슈 인프라와 사이트를 유지 관리하지 않아도 됩니다. 그만큼 Python 개발에 더 많은 시간과 자원을 쏟을 수 있습니다.
  • PR이 병합되면 이슈를 자동으로 닫을 수 있습니다 [6].
    • 이 기능은 bpo에도 있다는 점에 유의하십시오.
  • 기여의 진입 장벽이 낮아집니다. 사용자가 2,800만 명이 넘으므로 오픈 소스 기여자가 이미 계정을 가지고 있고 GitHub 인터페이스에 익숙할 가능성이 높아서 기여를 시작하기가 더 쉽습니다.
  • 메타데이터가 담긴 이메일 알림 [7]이 Gmail과 연동되어 이메일을 체계적으로 필터링할 수 있습니다. Roundup 이메일에도 일부 메타데이터가 들어 있지만 그만큼 풍부하지는 않습니다.
  • 사용자에게 이메일 주소를 숨길 수 있는 선택권을 주면서도 @-멘션으로 해당 사용자와 소통할 수 있게 하는 등 개인 정보 보호가 강화됩니다.

Roundup / bpo의 문제점

  • bpo를 유지 관리하는 사람은 다섯 명도 되지 않습니다. 그중 일부는 코어 개발자입니다.
  • 업스트림 Roundup 코드는 Mercurial에 있습니다. 사용할 수 있는 CI가 전혀 없기 때문에, 패치를 리뷰하고 테스트하고 적용하는 일이 몇 안 되는 기존 유지 관리자들에게 큰 부담이 됩니다. GitHub에 Roundup의 비공식 미러 [8]가 있기는 하지만, 여전히 Mercurial 패치가 Roundup에 기여하는 주된 방법입니다.

    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는 완벽한 이슈 트래커가 아닙니다. 우리가 알고 있어야 할 몇 가지 문제는 다음과 같습니다:

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

추가 질문과 논의

질문은 Discourse의 Core-Workflow 카테고리에 올릴 수 있습니다.

감사의 글

이 PEP의 초기 단계와 조사 과정에서 자문해 주신 Guido van Rossum, Brett Cannon, Alyssa Coghlan께 감사드립니다. 이분들의 피드백, 우려, 의견, 아이디어는 큰 도움이 되었습니다.

참고 문헌