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

Python 개선 제안 한국어 번역

PEP 595 – bugs.python.org 개선

Author:
Ezio Melotti <ezio.melotti at gmail.com>, Berker Peksag <berker.peksag at gmail.com>
BDFL-Delegate:
Barry Warsaw <barry at python.org>
Status:
Withdrawn
Type:
Informational
Created:
12-May-2019
Table of Contents

번역·라이선스 안내

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

초록

이 PEP는 기여자와 코어 개발자가 bugs.python.org를 더 편리하게 사용할 수 있도록 하는 개선 사항 목록을 제안합니다. 또한 이 PEP는 PEP 581에서 제안한 대로 GitHub Issues로 전환하기보다 Roundup을 계속 사용하는 편이 나은 이유를 논의합니다.

결정

2020-06-25: PEP 581이 수락되어 이슈를 GitHub로 옮기는 작업이 진행 중이므로, 이 PEP는 철회된 정보 PEP로 표시됩니다.

동기

2019년 5월 14일, PEP 581은 공개 논의가 거의 없이 명확한 합의도 없는 상태에서 수락되었습니다. 그 PEP에는 사실과 다른 내용이 들어 있으며, GitHub Issues로 이전할 때 생길 수 있는 몇 가지 문제를 다루지 않습니다.

마이그레이션의 범위, 필요한 작업량, 그리고 전환 단계 동안 워크플로에 미칠 부정적인 영향을 고려할 때, 이 결정은 재평가되어야 합니다.

GitHub Issues와 비교한 Roundup의 장점

이 절에서는 GitHub Issues보다 Roundup을 선호해야 하는 이유와 GitHub Issues에서는 제공되지 않는 Roundup의 기능을 논의합니다.

  • Roundup은 현재 상태입니다. Roundup은 수년간 CPython 워크플로의 필수적인 부분이었습니다. Roundup은 워크플로가 발전함에 따라 우리의 필요에 맞게 테스트되고 맞춤화된 안정적인 제품입니다.

    Roundup을 점진적으로 개선하면서, 다른 시스템으로 전환할 때 워크플로에 불가피하게 따르는 혼란을 피할 수 있습니다.

  • 오픈 소스이며 Python 기반입니다. Roundup은 오픈 소스 프로젝트이며 Python으로 작성되었습니다. Roundup을 사용하고 지원함으로써 우리는 Python 생태계도 지원하게 됩니다. 수년에 걸쳐 bpo를 위해 개발된 여러 기능이 업스트림 Roundup에도 이식되었습니다.
  • 완전히 맞춤화할 수 있습니다. Roundup은 우리의 필요에 맞게 완전히 맞춤화할 수 있으며, 실제로 그렇게 맞춤화되어 왔습니다.
  • 더 세분화된 접근 제어. Roundup에서는 개별 속성마다 서로 다른 권한(예: 생성, 조회, 편집 등)을 가진 여러 역할을 만들 수 있으며, 사용자는 여러 역할을 가질 수 있습니다.
  • 유연한 UI. Roundup UI는 낡아 보일 수 있지만, 편리하고 유연합니다.

    예를 들어, 이슈 페이지에서 각 필드(예: 제목, 유형, 버전, 상태, 연결된 파일과 PR 등)에는 설정하기 쉬운 적절한 UI 요소(입력 상자, 드롭다운, 표 등)가 있으며, 이를 통해 이슈에 관한 정보를 한눈에 편리하게 파악할 수 있습니다. 필드의 수와 그 값, 그리고 필드가 사용하는 UI 요소도 완전히 맞춤화할 수 있습니다. GitHub는 레이블만 제공합니다.

    이슈 목록 페이지는 필드마다 별도의 열이 있는, 간결하고 읽기 쉬운 표로 이슈를 보여 줍니다. 비교하자면, Roundup은 한 화면에 이슈 50개를 나열하는 반면, GitHub는 이슈 25개를 보여 주는 데 두 화면이 필요합니다.

  • 고급 검색. Roundup은 이슈 필드를 어떤 식으로 조합하든 정확하게 검색하고 필터링할 수 있는 방법을 제공합니다. 결과 수와 표에 표시되는 필드, 그리고 정렬과 그룹화(최대 두 단계)도 맞춤화할 수 있습니다.

    bpo는 미리 정의된 요약(예: “Created by you”, “Assigned to you” 등)도 제공하며, 사이드바에서 편리하게 접근할 수 있는 사용자 정의 검색 쿼리를 만들 수 있게 해 줍니다.

  • Nosy 목록 자동 완성. nosy 목록에는 유지 관리자와 전문가를 제안하는 자동 완성 기능이 있습니다. 전문가 색인이 변경되면 제안 목록이 자동으로 갱신됩니다.
  • 의존성과 대체 이슈. Roundup에서는 현재 이슈를 닫기 전에 해결해야 하는 의존성을 지정할 수 있습니다. 또한 중복 이슈를 쉽게 표시할 수 있도록 대체 이슈(superseder)도 지정할 수 있습니다(예: bpo-12078). 의존성 목록으로 다른 여러 하위 이슈를 참조하는 메타 이슈를 만들 수도 있습니다(예: bpo-26865).

Roundup 개선

이 절에서는 PEP 581에서 언급한 이슈 일부와 그 밖에 필요한 기능을 나열합니다. 그리고 Roundup이나 우리 인스턴스, 또는 둘 다를 개선하여 이를 어떻게 구현할 수 있는지 논의합니다.

  • REST API 지원. REST API가 있으면 다른 서비스와 통합하기 쉬워지고 새로운 도구와 애플리케이션도 더 쉽게 개발할 수 있습니다.

    업스트림 Roundup은 이제 REST API를 지원합니다. 트래커를 업데이트하면 REST API를 사용할 수 있습니다.

  • GitHub 로그인 지원. 이 기능이 있으면 사용자가 새 계정을 만들지 않고도 bugs.python.org(bpo)에 로그인할 수 있습니다. 확인 이메일이 스팸으로 분류되는 문제도 해결되고, 2단계 인증도 제공됩니다.

    이 기능을 추가하는 패치가 이미 나와 있으며 이 글을 쓰는 시점에 통합하는 중입니다.

  • Markdown 지원과 메시지 미리 보기 및 편집. 이 기능이 있으면 메시지에 Markdown을 사용할 수 있습니다. 또한 메시지를 제출하기 전에 미리 보고 제출한 뒤에 편집할 수 있습니다.

    구현할 수는 있지만 작업이 어느 정도 필요합니다. 가능한 해결책이 roundup-devel 메일링 리스트에 제안되어 있습니다.

  • “nosy 목록에서 나를 제거” 버튼. 이슈 페이지에 자신을 nosy 목록에서 제거하는 버튼을 추가합니다.

    이 기능은 GSoC 2019 기간에 추가될 예정입니다.

  • 모바일 친화적인 테마. bugs.python.org의 현재 테마는 낡아 보이고 모바일 브라우저에서 잘 작동하지 않습니다.

    더 현대적이면서도 여전히 익숙한 모바일 친화적 테마가 추가될 예정입니다.

  • 답장 상자를 마지막 메시지 가까이로 이동. 답장 상자는 페이지 맨 위에 있지만 마지막 메시지는 맨 아래에 있습니다.

    답장 상자를 마지막 메시지 뒤로 옮기거나 그 위치에 하나 더 둘 수 있습니다.

  • 실시간 업데이트. 다른 사용자가 이슈에 변경 사항을 제출하면 그 변경 사항이 실시간으로 표시되어야 합니다.

    REST API를 사용하면 이를 구현할 수 있습니다.

  • BPO 이메일에 PR 링크 추가. 현재 bpo 이메일에는 해당 PR로 가는 링크가 없습니다.

    bpo 이메일의 내용을 바꾸는 패치가 나와 있습니다. 변경 전:

    components: +Tkinter
versions: +Python 3.4
pull_requests: +42

    변경 후:

    components: +Tkinter
versions: +Python 3.4
pull_request: https://github.com/python/cpython/pull/341
  • Python 3 지원. Python 3을 사용하면 유지 보수가 쉬워집니다.

    업스트림 Roundup은 이제 Python 3을 지원합니다. 트래커를 업데이트하면 Python 3으로 전환할 수 있습니다. 인스턴스도 함께 업데이트해야 합니다.

  • 업스트림 Roundup 사용. 현재 우리는 몇 가지를 수정한 Roundup 포크를 사용하고 있습니다. 가장 대표적인 수정 사항은 GitHub 통합입니다. 이 수정 사항을 업스트림에 반영하면 포크를 따로 유지하지 않고도 업스트림 Roundup을 사용할 수 있습니다.

PEP 581의 문제점

이 절에서는 PEP 581에 있는 몇 가지 오류와 부정확한 내용을 다룹니다.

PEP 581의 “Why GitHub?” 절에는 현재 GitHub Issues에서는 사용할 수 있지만 Roundup에서는 사용할 수 없는 기능이 나열되어 있습니다. 이 기능 중 일부는 현재 지원되고 있습니다:

  • “이메일로 이슈와 풀 리퀘스트 대화에 답장할 수 있는 기능.”
    • 이메일로 답장할 수 있는 것은 처음부터 Roundup의 핵심 기능 중 하나였습니다. 새 이슈를 만들거나 기존 이슈를 닫고, 필드를 설정하거나 수정하고, 첨부 파일을 추가하는 것도 가능합니다.
  • “메타데이터를 포함하고 Gmail과 통합되어 이메일을 체계적으로 필터링할 수 있게 하는 이메일 알림.”
    • Roundup이 보내는 이메일에는 필터링에 사용할 수 있는 메타데이터가 포함되어 있습니다.
  • “사용자에게 이메일 주소를 숨길 수 있는 선택권을 주면서도 @-멘션을 통해 그 사용자와 계속 소통할 수 있게 하는 등의 추가적인 개인 정보 보호.”
    • 등록되지 않은 사용자에게는 이메일 주소가 기본적으로 숨겨집니다. 등록된 사용자는 다른 사용자의 주소를 볼 수 있는데, 이는 우리가 주소가 보이도록 트래커를 설정했기 때문입니다. 원한다면 이 설정은 쉽게 바꿀 수 있습니다. 주소가 숨겨져 있더라도 사용자 이름을 사용하면 해당 사용자를 nosy 목록에 추가할 수 있습니다.
  • “PR이 병합되면 이슈를 자동으로 닫는 기능.”
    • Roundup의 GitHub 통합 기능은 “fixes issue <id>”를 포함한 커밋이 병합되면 이슈를 자동으로 닫습니다. (“closes”나 “bug”(버그) 같은 다른 표기도 지원합니다.) 이 기능의 최근 예시는 이 메시지를 참고하십시오.
  • “고정 링크(permalink)를 지원하여 소스 코드를 쉽게 인용하고 복사하여 붙여 넣을 수 있게 하는 기능.”
    • Roundup에는 이슈, 메시지, 첨부 파일 등에 대한 고정 링크가 있습니다. 또한 Roundup에서는 (예를 들어 코드 호스팅이 바뀐 경우) 메시지 안의 깨진 URL을 쉽게 다시 쓸 수 있습니다.
  • “코어 개발자, 자원봉사자, PSF가 이슈 인프라/사이트를 유지 관리할 필요가 없으므로 Python 개발에 집중할 시간과 자원이 늘어납니다.”
    • 이 말이 부분적으로는 사실이지만, 봇을 작성하고 유지 관리하는 데에는 추가 자원이 필요합니다.

      어떤 경우에는 기능을 확장하기보다는 GitHub에 없는 기능을 우회하기 위해 봇이 필요합니다. 이 웹훅은 GitHub의 이메일 통합을 우회하기 위해 특별히 작성되었습니다.

      GitHub API의 변경 사항에 맞춰 봇을 최신 상태로 갱신하는 데에도 유지 관리 비용이 듭니다. GitHub이 일으킨 이 최근 사고는 해결하는 데 이틀이 걸렸습니다.

      또한 우리는 여전히 bpo(읽기 전용이 되더라도)와 현재 호스팅/유지 관리하는 다른 트래커(Jython과 Roundup)를 위해 Roundup을 유지 관리해야 합니다.

PEP 581의 “Issues with Roundup / bpo” 절에는 이미 해결된 몇 가지 문제가 나열되어 있습니다:

  • “업스트림 Roundup 코드는 Mercurial에 있습니다. 사용할 수 있는 CI가 없어서, 패치를 리뷰하고 테스트하고 적용하는 측면에서 소수의 기존 유지 관리자에게 큰 부담을 줍니다.”
  • “사용할 수 있는 REST API가 없습니다. Roundup에 REST API 추가를 위한 열린 이슈가 있습니다. 마지막 활동은 2016년이었습니다.”
    • REST API가 통합되어 이제 Roundup에서 사용할 수 있습니다.
  • “사용자의 이메일 주소가 노출됩니다. 이를 가릴 수 있는 옵션이 없습니다.”
    • 등록하고 로그인한 사용자에게 주소를 공개하는 것은 우리 인스턴스를 구축할 때 내린 결정이었습니다.

      이제는 일반 사용자에게도 이메일 주소가 보이지 않도록 변경되었습니다(Developers와 Coordinators는 여전히 볼 수 있습니다). 사용자 목록 페이지에서 “Email address” 열도 제거되었습니다.

  • “불필요한 이메일과 알림을 많이 보내며, 설정하기가 불가능하지는 않더라도 어렵습니다.”
    • 이는 설정할 수 있습니다.
  • “계정을 만드는 것이 번거로웠습니다. 계정을 만들거나 로그인하는 데 어려움을 겪었다는 보고가 있었습니다.”
    • 주된 문제는 확인 이메일이 스팸으로 분류되는 것입니다. 이 문제를 해결하기 위한 작업이 이루어졌습니다.

마이그레이션 고려 사항

이 절에서는 PEP 581과 PEP 588에서 다루지 않았을 수 있는 마이그레이션 관련 문제를 설명합니다.

PEP 588은 누군가 이슈에 대한 작업을 계속하려는 경우에만 해당 이슈를 GitHub로 마이그레이션하는 버튼을 추가할 것을 제안합니다. 이 접근 방식에는 여러 문제가 있지만, 어떤 접근 방식을 사용하든 해결해야 할 다른 문제들도 있습니다:

  • 벤더 잠금(lock-in). GitHub는 독점 서비스이므로 벤더 잠금의 위험이 있습니다. GitHub의 비즈니스 모델이 바뀔 수 있으며, 서비스가 완전히 종료될 수도 있습니다. 예를 들어, 여러 프로젝트가 Microsoft의 인수 이후 GitHub를 떠나기로 결정했습니다.

    저장소를 더 이상 GitHub에서 사용할 수 없게 된다면, 우리는 다시 마이그레이션해야 하며 이슈에 대한 모든 링크가 더 이상 작동하지 않게 됩니다.

  • 필요한 bpo 업데이트. bpo에 버튼을 추가하기 위해 bpo를 업데이트해야 합니다. 이 버튼을 누르면 GitHub에 새 이슈를 생성하고, 모든 메시지와 첨부 파일을 복사하며, 기존 필드에 대한 레이블을 생성하고 추가합니다. 또한 개별 이슈가 마이그레이션되면 읽기 전용이 되도록 하고, 사용자가 새 계정을 만들지 못하도록 권한도 조정해야 합니다. 리디렉션을 설정해야 할 수도 있습니다(아래 참조).
  • 두 개의 트래커. 이슈를 필요할 때마다 마이그레이션하면 이슈가 두 트래커로 나뉘게 됩니다. 이슈를 참조하고 검색하는 데 훨씬 더 많은 노력이 들 것입니다.
  • 손실이 있는 변환. GitHub에서 사용자 정의 메타데이터를 추가하는 유일한 방법은 레이블입니다. bpo는 여러 가지 다른 메타데이터를 지정하기 위해 많은 필드를 사용합니다. 모든 필드와 값을 보존하면 레이블이 지나치게 많아집니다. 일부 필드와 값만 보존하면 나머지는 사라지게 됩니다(다른 곳에 보존할 방법이 있지 않은 한).
  • 이슈 ID 보존. GitHub는 마이그레이션된 이슈의 ID를 지정하고 보존하는 방법을 제공하지 않습니다. 일부 프로젝트는 GitHub 직원에게 연락하여 이슈를 일괄적으로 마이그레이션함으로써 ID를 보존할 수 있었습니다. 그러나 PR과 이슈가 같은 네임스페이스를 공유하고 PR이 이미 기존 bpo 이슈 ID를 사용하고 있으므로, 이제는 이 방법이 불가능합니다.
  • 내부 이슈 링크 보존. 기존 이슈의 메시지와 필드(예: 의존성이나 superseder)에 다른 이슈에 대한 참조가 들어 있을 수 있습니다. 마이그레이션 중에 이슈 ID가 바뀌므로 이러한 참조를 업데이트해야 합니다. 이슈를 필요할 때마다 마이그레이션하는 경우, 마이그레이션된 이슈에 대한 기존의 모든 내부 참조(bpo 이슈와 GitHub 이슈 모두)를 업데이트해야 합니다.

    bpo에서 마이그레이션된 각 이슈에 리디렉션을 설정하면 문제를 완화할 수 있을지도 모릅니다. 그러나 마이그레이션된 메시지의 참조가 갱신되지 않으면 혼란이 생깁니다(예를 들어 bpo 이슈 #1234가 GitHub 이슈 #4321이 되는 경우, 마이그레이션된 메시지 안의 #1234 참조는 bpo #1234로 링크되고 bpo가 이를 GitHub 이슈 #4321로 리디렉션할 수 있습니다. 하지만 #1234에 대한 새 참조는 GitHub 이슈 #4321이 아니라 GitHub PR #1234로 링크됩니다). bpo- 또는 gh- 접두사를 수동으로 지정해야 하는 방식은 오류가 발생하기 쉽습니다.

  • 외부 이슈 링크 보존. 많은 웹사이트, 메일 등이 bpo 이슈로 링크합니다. bpo가 폐쇄되면 이 링크들이 깨집니다. 링크가 깨지지 않게 하려면 bpo를 계속 운영하면서 해당 GitHub 이슈로 연결하는 리디렉션 시스템을 구축해야 합니다.

    또한 GitHub가 서비스를 종료하면 리디렉션을 설정하여 GitHub 이슈로 향하는 외부 링크를 보존할 방법이 전혀 없습니다.

  • 참조 보존과 갱신. bpo는 이슈 참조 외에도 메시지 및 PR ID, 체인지셋 번호, 레거시 SVN 리비전 번호, 저장소 내 파일 경로, 트레이스백에 나오는 파일(올바른 브랜치 감지 포함), devguide 페이지 및 섹션 링크를 비롯한 여러 다른 참조를 링크로 변환합니다.

    Roundup은 메시지가 요청될 때 참조를 링크로 변환하므로 대상을 갱신하여 올바른 링크를 생성할 수 있습니다. 이런 필요는 이미 여러 번 생겼습니다. 예를 들어 파일과 HG 체인지셋이 hg.python.org에서 GitHub로 옮겨졌고, devguide가 docs.python.org/devguide에서 devguide.python.org로 옮겨졌습니다.

    GitHub의 메시지는 정적이므로 마이그레이션 중에 링크를 생성하여 하드코딩해야 합니다. 그렇게 하지 않으면 링크가 사라집니다. 이 링크를 갱신하려면 모든 참조를 찾아 링크를 다시 생성하는 도구를 작성해야 합니다.

  • Roundup과 bpo 유지 보수. 앞서 언급한 bpo 변경과 GitHub 이슈로 마이그레이션하는 데 필요한 도구 개발에 더해, 우리 bpo 인스턴스(읽기 전용)와 Jython 및 Roundup 트래커(읽기-쓰기) 모두를 위해 Roundup을 계속 운영하고 유지 보수해야 합니다.

    결국 모든 bpo 이슈를 GitHub로 마이그레이션하고 Jython과 Roundup의 유지 보수를 중단하더라도, bpo는 계속 유지 보수되어야 하며 해당 GitHub 이슈로 리디렉션해야 합니다.

  • 봇 유지 보수. GitHub는 직접 커스터마이즈할 수 없으므로 봇을 작성하고 유지 보수하고 호스팅해야 합니다. 결국 Roundup의 유지 보수를 중단하더라도 유지 보수 부담은 Roundup에서 봇으로 옮겨 갈 뿐입니다. 서로 다른 봇을 각각 호스팅하는 데에도 금전적 비용이 듭니다.
  • 이슈 템플릿 사용. “[해당] 이슈에 적용되지 않는 텍스트를 제거”하려고 이슈 템플릿을 수동으로 편집하는 일은 번거롭고 오류가 발생하기 쉽습니다.
  • 신호 대 잡음비. GitHub Issues로 전환하면 유효하지 않은 보고가 늘어나고 트리아지 작업 부담도 커질 가능성이 높습니다. 이 우려는 과거에 Zulip 토픽에서 제기된 적이 있습니다.

    사람들이 PR에 올린 댓글 때문에 중재자가 해당 댓글을 주제와 무관하거나 방해가 된다고 표시하거나, 아예 삭제하거나, 심지어 대화를 잠금 처리해야 했던 사례가 이미 있었습니다(예: 이 PR.

  • 주간 트래커 보고서와 통계. Roundup은 새 이슈, 답글이 없는 최근 이슈, 리뷰를 기다리는 최근 이슈, 가장 많이 논의된 이슈, 닫힌 이슈, 열린/닫힌/전체 이슈 수의 증감을 담은 요약과 함께 매주 python-dev에 보고서를 보냅니다(예를 들어 이 요약을 참고하십시오). 이 보고서는 트래커 활동을 쉽게 파악하고 주의가 필요한 이슈를 놓치지 않게 해 줍니다.

    주간 보고서가 수집한 데이터는 새로운 통찰을 얻는 데 쓸 수 있는 통계와 그래프를 생성하는 데에도 사용됩니다.

  • bpo 관련 메일링 리스트. 현재 bpo가 새 트래커 이슈와 모든 메시지를 각각 게시하는 메일링 리스트가 두 개 있습니다: new-bugs-announce와 python-bugs-list. 이 기능을 유지하려면 새로운 시스템을 개발해야 합니다. 이 메일링 리스트들은 트래커 활동을 파악하는 또 다른 방법을 제공합니다.