PEP 474 – forge.python.org 만들기

Author:: Alyssa Coghlan <ncoghlan at gmail.com>
Status:: Withdrawn
Type:: Process
Created:: 19-Jul-2014
Post-History:: 19-Jul-2014, 08-Jan-2015, 01-Feb-2015

Table of Contents

초록
PEP 철회
제안
근거
기대 효과
지속적 엔지니어링 고려 사항
개인적인 동기
기술적 우려 사항과 과제
시범 운영 목표 및 일정
CPython 코어 개발에 미칠 향후 영향
Copyright

번역·라이선스 안내

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

초록

이 PEP는 PSF가 제공하는 새 리소스인 forge.python.org를 만들어 여러 보조 저장소(파이썬 개선 제안 저장소 등)를 관리하는 장소로 쓸 것을 제안합니다. 이렇게 하면 새 기여자는 더 쉽게 참여할 수 있고 코어 개발자는 더 쉽게 관리할 수 있습니다.

이 PEP는 CPython 자체의 코어 개발 워크플로에 대한 어떠한 변경도 제안하지 않습니다(이와 관련해서는 PEP 462를 참조하십시오).

PEP 철회

이 PEP는 PEP 507의 GitLab 기반 제안을 지지하여 저자가 철회했습니다.

이 PEP를 이어받아 추진하고 싶은 분은 core-workflow 메일링 리스트에 연락하십시오.

제안

이 PEP는 자체 호스팅 코드 저장소 관리 시스템인 Kallithea의 인스턴스를 “forge.python.org”로 배포할 것을 제안합니다.

그런 다음 개별 저장소(개발자 가이드나 PEP 저장소 등)를 기존 hg.python.org 인프라에서 새 forge.python.org 인프라로 사안별로 이전할 수 있습니다. 이전할 때마다 hg.python.org에 읽기 전용 미러를 남길지, 아니면 새 위치로 통째로 옮길지 정해야 합니다.

forge.python.org는 hg.python.org의 읽기 전용 미러뿐만 아니라 GitHub이나 BitBucket 같은 인기 있는 독점 호스팅 사이트의 미러도 지원하는 것을 목표로 합니다. 목표는 이러한 사이트에 익숙한 사용자가 선호하는 워크플로대로 풀 리퀘스트를 제출하고 논의할 수 있게 하고, forge.python.org가 그 기여를 자동으로 마스터 저장소로 가져오게 하는 것입니다.

상업적 지원을 받는 “오픈 소스 프로젝트 무료” 저장소 호스팅 서비스가 널리 이용 가능하고 인기도 높다는 점을 고려할 때, 이 사이트는 임의의 Python 프로젝트를 위한 범용 호스팅 사이트가 되지는 않을 것입니다. 처음에는 특히 CPython과 현재 hg.python.org에 호스팅된 다른 저장소에 집중합니다. 나중에는 현재 외부에 호스팅된 다른 PSF 관리 저장소(python.org Django 애플리케이션 저장소 등)도 이곳으로 모아 풀 리퀘스트 기반 워크플로를 쓸 수 있도록 범위를 넓힐 수도 있습니다. 초기 이전과 마찬가지로, 앞으로의 이전도 각 저장소 주 사용자의 선호를 고려하여 사안별로 검토합니다.

근거

현재 hg.python.org에는 코어 CPython 저장소만 있는 것이 아닙니다. CPython 개발자 가이드 저장소와 파이썬 개선 제안 저장소 같은 다른 저장소도 있고, 코어 개발자가 실험하는 여러 “샌드박스” 저장소도 있습니다.

GitHub이나 BitBucket 같은 코드 호스팅 사이트가 널리 퍼뜨린 단순한 “풀 리퀘스트” 방식 워크플로는 여러 CPython 릴리스를 병렬로 유지 보수하고 개발하는 데 필요한 복잡한 브랜치 모델에는 적합하지 않습니다. 하지만 CPython을 둘러싼 여러 부속 프로젝트 중 독점 호스팅 사이트로 옮기고 싶지 않은 프로젝트에는 잘 맞습니다.

PSF가 제공하는 소프트웨어 포지에 제안하는 핵심 요구 사항은 다음과 같습니다:

단순한 “풀 리퀘스트” 방식 워크플로를 반드시 지원해야 합니다
간단한 변경을 위한 온라인 편집을 반드시 지원해야 합니다
활발한 개발 조직(커뮤니티 또는 기업)의 지원을 반드시 받아야 합니다
지속적인 비용 없이 PSF 인프라에서 마스터 저장소를 자체 호스팅할 수 있도록 반드시 지원해야 합니다

이 제안이 충족하는 추가 권장 요구 사항은 다음과 같습니다. 다만 충분히 설득력 있는 대안이 제시되면 협의할 수 있습니다:

Python으로 작성된 완전한 오픈 소스 애플리케이션이어야 합니다(SHOULD)
Mercurial을 지원하는 것이 바람직합니다(기존 도구와 일관성을 유지하기 위해)
Git을 지원하는 것이 바람직합니다(Git을 선호하는 사용자에게 그 선택지를 주기 위해)
git 클라이언트 사용자와 Mercurial 클라이언트 사용자가 같은 저장소에서 투명하게 협업할 수 있는 것이 바람직합니다
GitHub과 BitBucket 사용자가 그 도구에서 제공하는 표준 풀 리퀘스트 워크플로로 변경 제안을 제출할 수 있는 것이 바람직합니다
CPython 코어 개발에 필요한 사항에 맞게 사용자 정의할 수 있는 것이 바람직하며, 여기에는 PEP 462에서 제안한 코어 리뷰어 모델로 이전할 수 있는 길을 마련하는 것도 포함됩니다

지속적인 비용 없이 자체 호스팅하는 방식을 선호하므로, 여러 독점 소스 코드 관리 제품뿐만 아니라 GitHub나 BitBucket 같은 무료(free-as-in-beer) 제공업체도 제외됩니다.

Mercurial 지원을 선호하므로 GitHub뿐만 아니라 GitLab이나 Gitorious 같은 Git 전용 솔루션도 제외됩니다.

온라인 편집 지원은 필수 요구 사항이므로 Apache Allura/HgForge 조합은 제외됩니다.

완전한 오픈 소스 솔루션을 선호하므로 RhodeCode는 제외됩니다.

이 제안의 작성자가 검토한 여러 선택지 가운데 남는 것은 Kallithea SCM이며, 이를 forge.python.org 서비스의 기반으로 제안합니다.

Kallithea는 Software Freedom Conservancy의 후원 아래 개발되고 있는 완전한 GPLv3 애플리케이션입니다(RhodeCode에서 명확하고 모호함 없이 GPLv3로 라이선스된 구성 요소로부터 파생되었습니다). Conservancy는 Kallithea 코드베이스가 GPLv3에 따라 완전하고 유효하게 라이선스되어 있음을 확인했습니다. Conservancy는 초기 Kallithea 커뮤니티를 구축하는 역할 외에도 Mercurial 프로젝트와 Git 프로젝트 모두의 법적 소속 기관이기도 합니다. Python 사용자에게 익숙할 만한 다른 SFC 회원 프로젝트로는 Twisted, Gevent, BuildBot, PyPy가 있습니다.

기대 효과

Kallithea를 forge.python.org로 배포할 때의 주된 이점은 개발자 가이드나 PEP 저장소 같은 지원 저장소를 풀 리퀘스트와 온라인 편집으로 관리할 수 있게 될 가능성이 있다는 점입니다. 이는 다른 사용자가 제안한 업데이트를 적용하기 위해 PEP 편집자와 다른 코어 개발자가 중개자 역할을 해야 하는 현재 워크플로보다 훨씬 간단할 것입니다.

또한 더 풍부한 관리 기능 덕분에, 전체 설치본에 대한 일반 접근 권한을 부여하지 않고도 협업 목적으로 특정 저장소에 대한 접근 권한을 사용자에게 부여하는 일이 상당히 쉬워집니다. 코어 개발자 접근 권한 부여를 둘러싼 전부 아니면 전무식 결정이 아니라, 신뢰를 점진적으로 더 쉽게 부여하고 얻을 수 있으므로 진입 장벽을 낮추는 데 도움이 됩니다.

지속적 엔지니어링 고려 사항

현재의 워크플로로도 CPython 자체는 여전히 세계에서 가장 큰 오픈 소스 프로젝트 중 하나입니다(OpenHub에서 추적하는 프로젝트 중 상위 2%에 속합니다). 안타깝게도 우리는 CPython의 워크플로 인프라를 구성하는 프로젝트들에 대한 기여를 장려하는 데에는 상당히 덜 효과적이었으며, 여기에는 우리 설치본이 업스트림을 따라가도록 하는 일과 가능한 경우 우리 자체 커스터마이징을 원래 프로젝트에 다시 기여하도록 하는 일도 포함됩니다.

따라서 이 제안의 핵심 구성 요소는 업스트림 Kallithea 커뮤니티와 적극적으로 협력하여 Kallithea SCM을 사용하고 개발하는 데 따르는 장벽을 낮추는 것, 그리고 PSF 인프라 팀과 협력하여 forge.python.org 서비스가 PSF의 인프라 자동화와 깔끔하게 통합되도록 하는 것입니다.

이 접근 방식은 다음과 같은 여러 핵심 이점을 제공하는 것을 목표로 합니다:

이 서비스의 유지 관리에 기여하는 우리가 가용한 시간 안에서 최대한 생산적으로 일할 수 있게 합니다
이 서비스의 유지 관리에 참여하기로 한 자원봉사자에게 매력적인 전문성 개발 기회를 제공합니다
도입, 배포, 관리를 최대한 쉽게 만들어 Kallithea 프로젝트 자체를 다른 잠재 사용자에게 더 매력적으로 만듭니다
위 이점들의 결과로, 업스트림 Kallithea 커뮤니티와 CPython 인프라 커뮤니티 양쪽에서 충분한 기여자를 끌어들여 forge.python.org 서비스가 변화하는 개발자의 기대에 부응하도록 효과적으로 발전할 수 있게 합니다

이러한 지속적 엔지니어링 우려를 해결하기 위한 몇 가지 초기 조치가 이미 이루어졌습니다:

Tymoteusz Jankowski는 Donald Stufft와 함께 PSF의 Salt 기반 인프라 자동화를 사용하여 Kallithea를 배포하는 데 무엇이 필요한지 파악하는 작업을 해 왔습니다.
Graham Dumpleton과 저는 Red Hat의 오픈 소스 호스팅 서비스인 OpenShift Online의 무료 등급에 데모용 Kallithea 인스턴스를 쉽게 배포할 수 있도록 하는 작업을 해 왔습니다. (Graham의 후속 작업에 대한 링크는 해당 게시물의 댓글이나 quickstart 이슈 트래커를 참조하십시오.)

다음으로 수행할 주요 단계는 Windows, Mac OS X, Linux의 기여자가 자신의 시스템 동작을 방해하지 않고 로컬에서 Kallithea 테스트를 실행할 수 있는 로컬 개발 워크플로를 마련하는 것입니다. 현재 계획된 접근 방식은 Vagrant에 집중하는 것으로, Vagrant는 테스트 목적으로 로컬 VM을 실행하는 개발자를 특별히 겨냥한 인기 있는 자동화 가상 머신 관리 시스템입니다. OpenShift Origin의 Vagrant 기반 개발 지침은 이 접근 방식으로 가능해지는 워크플로의 확장된 예를 제공합니다. 또한 Vagrant가 python.org 메인 웹사이트의 로컬 빌드로 작업하기 위한 선택지 중 하나라는 점도 주목할 만합니다.

이러한 워크플로 제안이 Kallithea에서 잘 작동한다면, Roundup, BuildBot, python.org 메인 웹사이트를 포함하여 다른 PSF 및 CPython 인프라 서비스를 뒷받침하는 업스트림 프로젝트에도 사용을 제안해 볼 만할 것입니다.

개인적인 동기

2015년 7월 현재 저는 Red Hat에서 소프트웨어 개발 워크플로 설계자이자 프로세스 아키텍트로 일하고 있으며, Fedora의 업스트림 개발자 경험에 집중하고 있습니다. 그 경험의 핵심 요소 중 두 가지는 많은 웹 서비스 개발자에게 익숙할 것입니다. 로컬 컨테이너 관리를 위한 Docker와 크로스 플랫폼 로컬 개발 VM 관리를 위한 Vagrant입니다. 여러 업스트림 환경에서 이러한 기술을 적용하는 데 시간을 들이면 추가적인 통찰을 얻는 데 도움이 됩니다. Fedora에 잘 통합되어 있으면서도 다른 Linux 배포판, Windows, Mac OS X에서도 쉽게 사용할 수 있는 좋은 소프트웨어 개발 경험을 제공하기 위해 무엇이 잘 동작하는지, 그리고 무엇을 아직 더 개선해야 하는지를 알게 됩니다.

특히 코드 리뷰 워크플로와 관련하여, 제가 경력 동안 주로 사용한 코드 리뷰 워크플로 관리 도구는 Gerrit(세밀한 접근 제어를 갖춘 다단계 코드 리뷰용), GitHub와 BitBucket(기본적인 풀 리퀘스트 기반 워크플로용), 그리고 Rietveld(CPython의 선택적 커밋 전 리뷰용)입니다.

Kallithea는 기반으로 삼아 구축할 프로젝트로서 흥미롭습니다. 현재 저장소 호스팅과 코드 리뷰 관리를 결합한 플랫폼이지만, 온라인 병합을 제공하는 방식으로 이 둘을 직접 통합하지는 않기 때문입니다. 이는 업스트림 Kallithea 개발자들과 협력하여 Kallithea의 온라인 코드 병합 모델을 정의하는 과정에서, GitHub/BitBucket 풀 리퀘스트 모델의 낮은 진입 장벽이라는 이점과 Gerrit의 멘토링 및 작업 인계라는 이점을 결합할 기회를 만들어 줍니다.

기술적 우려 사항과 과제

CPython 인프라에 새로운 서비스를 도입하는 일에는 여러 가지 흥미로운 기술적 우려 사항과 과제가 따릅니다. 이 절에서는 그중 가장 중요한 몇 가지를 다룹니다.

서비스 호스팅

이 PEP의 기본 입장은 새로운 forge.python.org 서비스를 기존 PSF Salt 인프라에 통합하고 PSF의 Rackspace 클라우드 인프라에서 호스팅한다는 것입니다.

그러나 다른 호스팅 방안도 검토할 것입니다. 특히 GCEPersistentDisk나 오픈 소스 GlusterFS 분산 파일 시스템 중 하나를 사용해 소스 코드 저장소를 보관하면서, Google Container Engine 또는 Red Hat의 차세대 OpenShift Online 서비스에 Kubernetes 호스팅 웹 서비스로 배포하는 방안을 검토할 수 있습니다.

지속적인 인프라 유지 보수

지속적인 인프라 유지 보수는 PSF 내에서 우려되는 영역입니다. 현재 우리에게는 Fedora Infrastructure Apprentice 또는 GNOME Infrastructure Apprentice 프로그램에 상응하는 시스템 관리자 멘토링 프로그램이 없기 때문입니다.

대신 시스템은 주로 개발자들이 개발 관련 기여 외에 시간제 활동으로 유지 보수하는 경향이 있습니다. 개발(즉, 새로운 기능이나 더 나은 사용자 경험을 제공하거나 기존 문제를 해결하기 위해 서비스를 변경하는 일)보다 운영(즉, 기존 시스템이 계속 잘 돌아가도록 유지하는 일)에 더 관심이 있는 사람들을 모집하려 하지는 않습니다.

개인적으로는 언젠가 PSF가 그러한 프로그램을 운영하는 모습을 보고 싶지만, 그런 프로그램을 마련하는 것이 단기적으로 실현 가능한 목표라고 생각하지는 않습니다. 그러나 그러한 프로그램을 위한 기반을 계속 다져 나가는 것은 실현 가능하다고 생각합니다. PSF가 이미 사용하고 있는 OpenStack과 Salt 같은 현대적인 인프라 기술을 더 많은 서비스로 확대하고, PSF가 제공하는 서비스를 유지 보수하고 개선하는 데 컨테이너와 컨테이너 플랫폼이 줄 수 있는 잠재적 이점을 탐색하기 시작하면 됩니다.

또한 ManageIQ와 같은 오픈 소스 클라우드 관리 플랫폼이 Rackspace, Google, Amazon 및 기타 서비스에 걸쳐 새로 나타나고 있는 “클라우드 스프롤(cloud sprawl)” 문제를 더 잘 통제하는 데 도움이 될 수 있는지도 살펴볼 계획입니다.

사용자 계정 관리

이상적으로는 Kallithea, Roundup/Rietveld, PyPI, 새 python.org 사이트의 백엔드를 포함한 모든 python.org 서비스에 걸쳐 쓸 수 있는 단일 계정을 제공하고 싶지만, 실제로 이를 구현하는 것은 이 PEP와는 무관한 별개의 인프라 프로젝트가 될 것입니다. (그러한 기능이 제공하는 세밀한 ACL 제어는 효과적인 시스템 관리자 멘토링 프로그램을 마련하기 위한 전제 조건이라는 점도 짚어 둘 만합니다.)

forge.python.org의 초기 출시에서는 아마도 PSF 인프라 안에 또 하나의 ID 사일로를 만들게 될 것입니다. 잠재적으로 더 나은 대안은 Kallithea에 python-social-auth 지원을 추가하는 것이지만, 실제로 그렇게 하는 것이 서비스 초기 출시의 필수 요건은 아닙니다(여기서 주된 기술적 우려는 Kallithea가 아직 Pyramid로 포팅되지 않은 Pylons 애플리케이션이라는 점이므로, 통합하려면 python-social-auth에 Pylons 백엔드를 추가하거나 Kallithea의 Pyramid 마이그레이션에 착수해야 합니다).

Mercurial 저장소에 대한 기존 SSH 접근 및 링크가 깨지는 문제

이 PEP는 기존 hg.python.org 설치는 그대로 두고, 새 호스트에 Kallithea를 설정할 것을 제안합니다. 이 방식은 CPython 자체(및 새 소프트웨어 포지로 이전하지 않는 다른 모든 프로젝트)의 개발을 방해할 위험을 최소화하지만, 기존 저장소를 이전할 때는 더 큰 혼란을 초래합니다(기존 체크아웃이 깨지기 때문입니다).

Roundup과의 통합

Kallithea는 설정 가능한 이슈 트래커 통합 기능을 제공합니다. forge.python.org 서비스의 초기 출시 전에 bugs.python.org의 Roundup 이슈 트래커와 통합되도록 이를 적절히 설정해야 합니다.

GitHub와 BitBucket에서 풀 리퀘스트 받기

forge.python.org의 초기 출시는 hg.python.org와 다른 서비스 모두에 읽기 전용 미러를 게시하는 기능을 지원할 것입니다. 이는 커밋 훅으로 구현할 수 있는 비교적 간단한 작업이기 때문입니다.

외부 서비스에서 풀 리퀘스트를 받아 forge.python.org의 마스터 저장소에 대한 제출로 미러링하는 기능은 매우 바람직하지만 더 복잡한 문제이므로, forge.python.org 서비스의 초기 출시에는 포함되지 않을 가능성이 높습니다.

투명한 Git 및 Mercurial 상호 운용성

Kallithea는 Git과 Mercurial을 모두 기본 지원하므로, 개발자가 원하는 클라이언트로 forge.python.org에 호스팅된 저장소를 비교적 쉽게 다룰 수 있게 만들 기회를 제공합니다.

이러한 투명한 상호 운용성은 아직 존재하지 않지만, 자체 다중 VCS 저장소 호스팅 서비스를 운영하면 독점 서비스 제공자가 자사의 상업적 이익에 맞지 않을 가능성이 높은 기능을 선심 쓰듯 제공해 주기만을 수동적으로 기다리는 대신, 이 기능을 직접 실현할 기회를 얻게 됩니다. 이 특정 영역에서는 오픈 소스 커뮤니티와 상업적 서비스 제공자 사이의 동기가 크게 어긋나 있습니다. VCS 클라이언트 선택권을 제공하면 프로젝트가 잠재적 기여자에게 특정 도구 선택을 강요하는 독단적인 결정을 내릴 필요가 없어져 커뮤니티 내 마찰을 크게 줄일 수 있지만, GitHub와 Atlassian의 유료 고객을 만들어 내는 기업 및 기타 조직 환경에서는 (개발자의 선호와 관계없이) 하향식으로 도구 선택을 강제하는 것이 현재도 여전히 일반적이기 때문입니다.

투명한 상호 운용성이 갖추어지지 않은 상황이라면, 이 PEP는 채택 전에 forge.python.org에 호스팅된 Mercurial 저장소에 풀 리퀘스트를 생성하는 방법에 관하여 CPython 개발자 가이드의 git 사용자 섹션에 포함할 구체적인 권장 사항을 제안해야 합니다.

시범 운영 목표 및 일정

[TODO: Brett의 수정된 일정에 맞춰 이 섹션을 갱신하십시오. 수정된 일정은 지원 저장소뿐만 아니라 CPython 자체가 새 시스템으로 이전한 이후의 향후 기능을 더 잘 가늠할 수 있도록, 10월 31일까지 CPython 데모 저장소를 온라인으로 운영하는 것을 목표로 합니다]

이 제안은 CPython 개발 워크플로의 여러 측면에 대한 개선 제안을 검토하는 Brett Cannon의 현재 평가 과정의 일부입니다. 해당 일정의 주요 날짜는 다음과 같습니다:

2월 1일: 제안 초안 발표 (Kallithea의 경우 이 PEP)
4월 8일: Python 언어 서밋에서 최종 제안 논의
5월 1일: 어떤 제안을 채택할지에 대한 Brett의 결정
9월 13일: Python 3.5 출시, Python 3.6부터 새 워크플로 채택

이 제안이 추가 개발 대상으로 선정되면, 다음과 같은 시범 배포부터 시작할 것을 제안합니다:

kallithea-pilot.python.org에서 운영되며 최소한 개발자 가이드와 PEP 저장소를 포함하는 참조 구현. 이 인스턴스는 “일회용”이므로, 코어 개발자와 기타 기여자는 저장소 이력에 미칠 장기적인 영향을 걱정하지 않고 자유롭게 실험할 수 있습니다.
GitHub와 BitBucket에 있는, Kallithea 호스팅 저장소의 읽기 전용 실시간 미러. 시범 서비스 자체와 마찬가지로 이 저장소들도 임시 저장소이며, 시범 기간이 끝나면 폐기됩니다.
이 미러를 사용하여 Kallithea에 호스팅된 Mercurial 저장소에 풀 리퀘스트를 생성하는 방법에 대한 명확한 문서 (시범 운영에서는 해당 호스팅 서비스 고유의 풀 리퀘스트 워크플로를 사용하는 방법은 포함하지 않을 가능성이 높습니다)
코드 리뷰 댓글과 커밋 메시지에 있는 이슈 참조를 bugs.python.org의 해당 이슈에 자동으로 연결하는 기능
Kallithea 기반의 PEP 편집 및 제출 워크플로를 설명하는 PEP 1의 갱신 초안

다음 항목들은 프로덕션 이전에 필요하지만, 시범 운영 과정에서 갱신된 구현을 시험해 볼 뚜렷한 방법은 없는 것으로 보입니다:

이전된 Mercurial 저장소를 기반으로 PEP 게시 절차와 개발자 가이드 게시 절차를 조정하는 작업

다음 항목들은 전체 워크플로 개선 과정의 목표이지만, (이 제안이 선정되고 제안된 시범 배포가 성공할 경우) 9월에 새 서비스를 처음 도입하는 데에는 “바람직하지만 필수적이지는 않은” 것으로 간주됩니다:

python-social-auth를 사용하여 PSF가 호스팅하는 Kallithea 인스턴스에 인증할 수 있도록 하는 기능
GitHub와 BitBucket의 풀 리퀘스트 워크플로를 사용하여 주 Kallithea 저장소에 풀 리퀘스트를 제출할 수 있도록 하는 기능
Kallithea에 호스팅된 저장소와 풀 리퀘스트를 기반으로 BuildBot 강제 실행을 손쉽게 트리거할 수 있도록 하는 기능 (PEP 462 구현 이전에는 주 CPython 저장소가 아닌 샌드박스 저장소에서 사용하기 위한 것입니다)

CPython 코어 개발에 미칠 향후 영향

주 CPython 개발 저장소의 워크플로 요구 사항은 이 PEP에서 다루는 저장소들의 요구 사항보다 훨씬 더 복잡합니다. 이러한 사항은 PEP 462에서 더 자세히 다룹니다.

Rietveld를 더 활발하게 유지 관리되는 코드 리뷰 시스템으로 교체하라는 Guido의 권고에 따라, 현재 저는 Kallithea를 제안된 연결 계층으로 사용하도록 해당 PEP를 다시 작성할 계획입니다. 이렇게 하면 기능이 향상된 Kallithea 풀 리퀘스트가 패치 파일을 이슈 트래커에 직접 업로드하는 현재 방식을 결국 대체하게 됩니다.

저는 또한 Pierre Yves-David와 함께 CPython 코어 개발 워크플로의 일부 측면을 자동화하는 사용자 정의 Mercurial 확장 작업을 시작했습니다.

Copyright

This document has been placed in the public domain.