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 작업 흐름의 핵심 부분이었습니다. 작업 흐름이 발전함에 따라 우리의 필요에 맞도록 테스트되고 맞춤화된 안정적인 제품입니다.

    점진적으로 개선하여 다른 시스템으로 전환할 때 작업 흐름에 필연적으로 발생하는 중단을 피할 수 있습니다.

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

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

    이슈 목록 페이지는 서로 다른 필드에 대해 별도의 열을 사용하여 이슈를 간결하고 읽기 쉬운 표로 표시합니다. 비교해 보면 Roundup은 한 화면에 50개의 이슈를 표시하는 반면, GitHub는 25개의 이슈를 표시하는 데 두 화면이 필요합니다.

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

    bpo는 미리 정의된 요약(예: “내가 생성함”, “내게 할당됨” 등)도 제공하며 사이드바에서 편리하게 액세스할 수 있는 사용자 지정 검색 쿼리를 만들 수 있도록 합니다.

  • Nosy 목록 자동 완성입니다. Nosy 목록에는 유지 관리자와 전문가를 제안하는 자동 완성 기능이 있습니다. experts index가 변경되면 제안 항목이 자동으로 업데이트됩니다.
  • 의존성과 대체 이슈. Roundup을 사용하면 현재 이슈를 종료하기 전에 처리해야 하는 의존성과 중복 이슈를 쉽게 표시하기 위한 대체 이슈를 지정할 수 있습니다(예: bpo-12078). 의존성 목록을 사용하여 여러 다른 하위 이슈를 참조하는 메타 이슈를 만들 수도 있습니다(예: bpo-26865).

Roundup 개선

이 절에서는 PEP 581에서 언급된 일부 이슈와 그 밖에 원하는 기능을 나열하고, Roundup 및/또는 우리의 인스턴스를 개선하여 이를 구현하는 방법을 논의합니다.

  • REST API 지원. REST API를 사용하면 다른 서비스와의 통합 및 새로운 도구와 애플리케이션의 개발이 쉬워집니다.

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

  • GitHub 로그인 지원. 이를 통해 사용자는 새 계정을 만들지 않고도 bugs.python.org(bpo)에 로그인할 수 있습니다. 또한 확인 이메일이 스팸으로 표시되는 문제를 해결하고, 2단계 인증을 제공할 수 있습니다.

    이 기능을 추가하는 패치는 already available이며, 작성 시점에 통합되고 있습니다.

  • Markdown 지원 및 메시지 미리 보기와 편집. 이 기능을 사용하면 메시지에서 Markdown을 사용하고, 제출하기 전에 메시지를 미리 보며 제출한 후에 편집할 수 있습니다.

    이 작업은 가능하지만 어느 정도 작업이 필요합니다. 가능한 해결책이 roundup-devel mailing list에 제안되어 있습니다.

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

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

  • 모바일 친화적 테마. 현재 bugs.python.org의 테마는 오래되어 보이며 모바일 브라우저에서 제대로 작동하지 않습니다.

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

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

    답글 상자를 마지막 메시지 뒤로 이동하거나 복제할 수 있습니다.

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

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

  • BPO 이메일에 PR 링크 추가. 현재 bpo 이메일에는 해당 PR에 대한 링크가 포함되어 있지 않습니다.

    bpo 이메일의 내용을 다음에서 변경하는 데 사용할 수 있는 patch가 있습니다:

    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에서 발견된 일부 오류와 부정확한 내용을 다룹니다.

“Why GitHub?” 섹션은 PEP 581의 GitHub Issues에서는 현재 사용할 수 있지만 Roundup에서는 사용할 수 없는 기능을 나열합니다. 이러한 기능 중 일부는 현재 지원됩니다.

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

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

      GitHub API의 변경 사항에 맞춰 봇을 최신 상태로 유지하는 데에도 유지 관리 비용이 발생합니다. This recent incident caused by GitHub을 해결하는 데 이틀이 걸렸습니다.

      또한 bpo용 Roundup(읽기 전용이 되더라도)과 현재 호스팅하거나 유지 관리하는 다른 트래커들(Jython및 Roundup)도 계속 유지 관리해야 합니다.

“Issues with Roundup / bpo” 섹션은 PEP 581의 이미 해결된 일부 문제를 나열합니다:

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

      이제 일반 사용자에게도 이메일 주소가 숨겨지도록 변경되었습니다(개발자와 코디네이터는 여전히 이메일 주소를 볼 수 있습니다). 사용자 목록 페이지의 “이메일 주소” 열도 제거되었습니다.

  • “불필요한 이메일과 알림을 여러 건 보내며, 구성하기가 어렵거나 불가능합니다.”
    • 구성할 수 있습니다.
  • “계정을 만드는 일은 번거로웠습니다. 계정을 만들거나 로그인하는 데 어려움을 겪었다는 보고가 있었습니다.”
    • 주요 문제는 확인 이메일이 스팸으로 표시되는 것입니다. 문제를 해결하기 위한 작업이 진행되었습니다.

마이그레이션 고려 사항

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

PEP 588은 누군가 이슈에 대한 작업을 계속하고 싶은 경우에만 이슈를 GitHub로 마이그레이션하는 버튼을 추가할 것을 제안합니다. 이 접근 방식에는 몇 가지 문제가 있지만, 사용한 접근 방식과 관계없이 해결해야 하는 다른 문제도 있습니다.

  • 벤더 종속. GitHub는 독점적이며 벤더 종속의 위험이 있습니다. GitHub의 비즈니스 모델이 바뀌어 완전히 종료될 수도 있습니다. 예를 들어 Microsoft가 인수한 후 여러 프로젝트가 GitHub에서 벗어나기로 결정했습니다.

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

  • 필요한 bpo 업데이트. bpo에는 버튼을 추가하기 위한 업데이트가 필요합니다. 이 버튼을 누르면 GitHub에 새 이슈를 만들고, 모든 메시지와 첨부 파일을 복사하며, 기존 필드에 대한 레이블을 생성하거나 추가합니다. 또한 마이그레이션이 완료된 개별 이슈를 읽기 전용으로 만들고 사용자가 새 계정을 만들지 못하도록 권한을 조정해야 합니다. 리디렉션을 설정해야 할 수도 있습니다(아래 참조).
  • 두 개의 트래커. 요청에 따라 이슈를 마이그레이션하면 이슈가 두 트래커로 나뉘게 됩니다. 이슈를 참조하고 검색하는 데 훨씬 더 많은 노력이 필요합니다.
  • 손실 변환. GitHub에서 사용자 지정 메타데이터를 추가하는 유일한 방법은 레이블을 통하는 것입니다. bpo는 여러 종류의 메타데이터를 지정하기 위해 여러 필드를 사용합니다. 모든 필드와 값을 보존하면 레이블이 지나치게 많아집니다. 일부 필드와 값만 보존하면 나머지는 손실됩니다(다른 곳에 보존할 방법이 없는 경우).
  • 이슈 ID 보존. GitHub는 마이그레이션된 이슈의 ID를 설정하고 보존할 방법을 제공하지 않습니다. 일부 프로젝트는 GitHub 담당자에게 문의하고 이슈를 일괄적으로 마이그레이션하여 ID를 보존할 수 있었습니다. 그러나 PR과 이슈가 동일한 네임스페이스를 공유하고 PR이 이미 기존 bpo 이슈 ID를 사용하고 있으므로 이제는 더 이상 불가능합니다.
  • 내부 이슈 링크 보존. 기존 이슈에는 메시지와 필드에 다른 이슈에 대한 참조가 포함되어 있을 수 있습니다(예: 종속성 또는 대체 이슈). 마이그레이션 중에 이슈 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 이슈로 마이그레이션하는 데 필요한 도구 개발에 더해, 우리는 여전히 Roundup을 계속 실행하고 유지 관리해야 할 것입니다. 이는 우리의 bpo 인스턴스(읽기 전용)와 Jython 및 Roundup 트래커(읽기/쓰기) 모두에 해당합니다.

    결국 모든 bpo 이슈를 GitHub로 마이그레이션하고 Jython과 Roundup 유지 관리를 중단하더라도, bpo는 유지 관리되면서 해당 GitHub 이슈로 리다이렉트되어야 할 것입니다.

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

    사람들이 PR에 댓글을 게시하여 모더레이터가 이를 주제와 무관하거나(off-topic) 방해가 되는 것으로 표시하고, 완전히 삭제하며, 심지어 대화를 잠가야 했던 사례가 이미 있었습니다(예: 이 PR).

  • 주간 트래커 보고서 및 통계. Roundup은 python-dev에 새 이슈, 최근 답변 없는 이슈, 최근 검토 대기 중인 이슈, 가장 많이 논의된 이슈, 종료된 이슈, 그리고 열림/닫힘/전체 이슈 수의 증감을 포함한 요약과 함께 주간 보고서를 보냅니다(예: 이 요약을 참조하십시오). 이 보고서는 트래커 활동을 추적하고 주의가 필요한 이슈가 확실히 인지되도록 하는 손쉬운 방법을 제공합니다.

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

  • bpo 관련 메일링 리스트. 현재 bpo가 새 트래커 이슈와 모든 메시지를 각각 게시하는 두 개의 메일링 리스트가 있습니다: new-bugs-announce와 python-bugs-list. 이 기능을 보존하려면 새로운 시스템을 개발해야 할 것입니다. 이러한 메일링 리스트는 트래커 활동을 추적할 수 있는 추가적인 방법을 제공합니다.