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 철회
• 제안
• 근거
• 예상되는 이점
• 지속 가능한 엔지니어링 고려 사항
• 개인적 동기
• 기술적 우려 사항 및 과제
  • 서비스 호스팅
  • 지속적인 인프라 유지 관리
  • 사용자 계정 관리
  • Mercurial 저장소에 대한 기존 SSH 액세스 및 링크의 중단
  • Roundup과의 통합
  • GitHub 및 BitBucket에서 풀 리퀘스트 수락
  • 투명한 Git 및 Mercurial 상호 운용성
• 파일럿 목표 및 일정
• CPython 핵심 개발에 대한 향후 영향
• Copyright

번역·라이선스 안내

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

초록

이 PEP는 새로운 PSF 제공 리소스인 forge.python.org를 다양한 지원 저장소(예: Python 개선 제안 저장소)를 새 기여자가 더 쉽게 접근하고 핵심 개발자가 더 쉽게 관리할 수 있는 위치로 설정할 것을 제안합니다.

이 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에 읽기 전용 미러를 유지할지, 아니면 새로운 위치로 전체를 마이그레이션할지를 결정해야 합니다.

hg.python.org의 읽기 전용 미러를 지원하는 것 외에도 forge.python.org는 GitHub 및 BitBucket과 같은 인기 있는 독점 호스팅 사이트에서 미러를 호스팅하는 것도 지원하는 것을 목표로 합니다. 목표는 이러한 사이트에 익숙한 사용자가 선호하는 작업 흐름을 사용하여 풀 리퀘스트를 제출하고 논의할 수 있도록 하며, forge.python.org가 해당 기여를 마스터 저장소로 자동으로 가져오도록 하는 것입니다.

상업적으로 지원되는 “오픈 소스 프로젝트를 위한 무료” 저장소 호스팅 서비스가 이용 가능하고 인기가 있다는 점을 고려하면, 이는 임의의 Python 프로젝트를 위한 범용 호스팅 사이트가 되지는 않을 것입니다. 초기 초점은 특히 CPython과 현재 hg.python.org에서 호스팅되는 기타 저장소에 맞춰질 것입니다. 향후에는 풀 리퀘스트 기반 작업 흐름을 이용할 수 있도록 현재 외부에서 호스팅되는 다른 PSF 관리 저장소를 통합하는 방향으로 이를 확장할 수도 있습니다. 예를 들어 python.org Django 애플리케이션의 저장소가 이에 해당합니다. 초기 마이그레이션과 마찬가지로 이러한 향후 마이그레이션도 각 저장소의 주요 사용자 선호도를 고려하여 사안별로 검토합니다.

근거

현재 hg.python.org는 CPython 핵심 저장소뿐만 아니라 CPython 개발자 가이드와 Python 개선 제안용 저장소, 그리고 핵심 개발자의 실험을 위한 다양한 “샌드박스” 저장소도 호스팅합니다.

GitHub와 BitBucket 같은 코드 호스팅 사이트에서 대중화된 단순한 “풀 리퀘스트” 방식의 작업 흐름은 여러 CPython 릴리스의 병렬 유지 관리 및 개발에 필요한 복잡한 브랜칭 모델에는 적합하지 않지만, CPython을 둘러싼 여러 부수 프로젝트에는 잘 맞으며 이러한 프로젝트를 독점 호스팅 사이트로 옮기기를 원하지 않습니다.

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

• 단순한 “풀 리퀘스트” 방식의 작업 흐름을 반드시 지원해야 합니다.
• 간단한 변경 사항에 대한 온라인 편집을 반드시 지원해야 합니다.
• 활발한 개발 조직(커뮤니티 또는 상업 조직)의 지원을 반드시 받아야 합니다.
• 지속적인 비용 없이 PSF 인프라에서 마스터 저장소를 자체 호스팅하는 것을 반드시 지원해야 합니다.

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

• Python으로 작성된 완전한 오픈 소스 애플리케이션이어야 합니다.
• 기존 도구와의 일관성을 위해 Mercurial을 지원해야 합니다.
• 이를 선호하는 사용자에게 해당 선택지를 제공하기 위해 Git을 지원해야 합니다.
• git 및 Mercurial 클라이언트 사용자가 동일한 저장소에서 투명하게 협업할 수 있도록 해야 합니다.
• GitHub 및 BitBucket 사용자가 해당 도구에서 제공하는 표준 풀 리퀘스트 작업 흐름을 사용하여 제안된 변경 사항을 제출할 수 있도록 해야 합니다.
• CPython 핵심 개발의 요구를 충족하도록 사용자 지정에 개방적이어야 하며, PEP 462에서 제안된 핵심 리뷰어 모델로의 마이그레이션을 위한 잠재적인 전진 경로를 제공하는 것도 포함해야 합니다.

지속적인 비용 없이 자체 호스팅하는 것을 선호하므로, 다양한 독점 소스 코드 관리 제품뿐만 아니라 GitHub와 BitBucket 같은 무료 서비스 제공업체도 제외됩니다.

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

온라인 편집 지원을 반드시 요구하므로 Apache Allura/HgForge 조합은 제외됩니다.

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

이 제안의 작성자가 고려한 다양한 선택지 가운데, forge.python.org 서비스를 위한 제안된 기반으로는 Kallithea SCM을 선택할 수 있습니다.

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

예상되는 이점

Kallithea를 forge.python.org로 배포할 때의 주요 이점은 개발자 가이드와 PEP 저장소 같은 지원 저장소를 풀 리퀘스트와 온라인 편집을 사용하여 관리할 수 있다는 점입니다. 이는 다른 사용자가 제안한 업데이트를 적용하기 위해 PEP 편집자와 다른 핵심 개발자가 중개자 역할을 해야 하는 현재 작업 흐름보다 훨씬 간단합니다.

더욱 풍부한 관리 기능을 사용하면 전체 설치 환경에 대한 일반적인 접근 권한을 부여하지 않고도 협업을 목적으로 특정 저장소에 대한 사용자 접근 권한을 부여하기가 훨씬 쉬워집니다. 이를 통해 진입 장벽을 낮출 수 있습니다. 핵심 개발자 접근 권한 부여 여부를 전부 아니면 전무로 결정하는 대신, 신뢰를 더 쉽게 점진적으로 부여하고 쌓을 수 있기 때문입니다.

지속 가능한 엔지니어링 고려 사항

현재 작업 흐름에서도 CPython 자체는 OpenHub에서 추적하는 프로젝트 중 top 2%에 속하는 세계 최대 규모의 오픈 소스 프로젝트 중 하나로 남아 있습니다. 안타깝게도 CPython의 작업 흐름 인프라를 구성하는 프로젝트에 대한 기여를 장려하는 데에는 상당히 덜 효과적이었습니다. 여기에는 설치 환경이 업스트림을 추적하도록 보장하는 일과, 가능한 경우 자체 맞춤 변경 사항을 원래 프로젝트에 기여하는 일이 포함됩니다.

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

이 접근 방식은 다음과 같은 주요 이점을 제공하는 것을 목표로 합니다.

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

이러한 지속 가능한 엔지니어링 관련 우려를 해결하기 위한 몇 가지 초기 단계는 이미 진행되었습니다.

• Tymoteusz Jankowski는 PSF의 Salt 기반 인프라 자동화를 사용하여 Kallithea를 배포할 때 what would be involved을 파악하기 위해 Donald Stufft와 협력해 왔습니다.
• Graham Dumpleton과 저는 Red Hat의 오픈 소스 호스팅 서비스인 OpenShift Online의 무료 등급에 시연용 Kallithea 인스턴스를 쉽게 배포할 수 있도록 쉽게 만들기를 위한 작업을 해 왔습니다. (해당 게시물의 댓글이나 Graham의 후속 작업 링크가 있는 빠른 시작 이슈 트래커를 참조하십시오.)

다음으로 수행할 주요 단계는 Windows, Mac OS X 및 Linux의 기여자가 자신의 시스템 작동을 방해하지 않고 Kallithea 테스트를 로컬에서 실행할 수 있도록 하는 로컬 개발 작업 흐름을 마련하는 것입니다. 현재 계획된 접근 방식은 Vagrant에 집중하는 것입니다. Vagrant는 테스트 목적으로 로컬 VM을 실행하는 개발자를 특별히 대상으로 하는 널리 사용되는 자동화된 가상 머신 관리 시스템입니다. OpenShift Origin의 Vagrant based development guidelines은 이 접근 방식으로 가능해지는 작업 흐름의 유형을 확장된 예제로 제공합니다. Vagrant가 main python.org website의 로컬 빌드로 작업하기 위한 선택지 중 하나라는 점도 언급할 가치가 있습니다.

이러한 작업 흐름 제안이 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 distributed filesystem을 사용하여 소스 코드 저장소를 보관하고, Kubernetes 호스팅 웹 서비스로 Google Container Engine 또는 Red Hat의 차세대 OpenShift Online 서비스에 배포하는 방안을 고려할 것입니다.

지속적인 인프라 유지 관리

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

그 대신 시스템은 기존 시스템을 원활하게 운영하는 데 관심이 있는 사람을 개발, 즉 새로운 기능이나 더 나은 사용자 경험을 제공하거나 기존 문제를 해결하기 위해 서비스를 변경하는 데 관심이 있는 사람보다 우선적으로 채용하기보다는, 개발자들이 개발 관련 기여에 더해 시간제 활동으로 주로 유지 관리하는 경향이 있습니다.

개인적으로는 언젠가 PSF가 이러한 프로그램을 운영하는 모습을 보고 싶지만, 이를 마련하는 것을 가까운 시일 내에 달성 가능한 목표라고는 생각하지 않습니다. 그러나 OpenStack과 Salt 같은 현대적인 인프라 기술을 PSF가 기존에 사용하던 범위에서 더 많은 서비스로 확장하고, 컨테이너와 컨테이너 플랫폼이 PSF가 제공하는 서비스를 유지 관리하고 개선하는 데 가져올 수 있는 잠재적 이점을 탐색하기 시작함으로써, 그러한 프로그램을 위한 기반을 계속 마련하는 것은 가능하다고 생각합니다.

또한 ManageIQ와 같은 오픈 소스 클라우드 관리 플랫폼이 Rackspace, Google, Amazon 및 기타 서비스 전반에 걸쳐 점점 커지고 있는 “클라우드 확산” 문제를 보다 효과적으로 통제하는 데 도움이 될 수 있는지 살펴볼 계획입니다.

사용자 계정 관리

이상적으로는 Kallithea, Roundup/Rietveld, PyPI 및 새로운 python.org 사이트의 백엔드를 포함한 모든 python.org 서비스에서 사용할 수 있는 단일 계정을 제공하고 싶지만, 이를 실제로 구현하는 것은 이 PEP와는 독립적인 별도의 인프라 프로젝트가 될 것입니다. (또한 이러한 기능이 제공하는 ACL의 세밀한 제어가 effective system administrator mentorship program을 마련하기 위한 전제 조건이라는 점도 언급할 필요가 있습니다.)

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: 브렛의 수정된 일정에 맞춰 이 섹션을 업데이트할 것. 이 일정은 지원 저장소뿐 아니라 CPython 자체가 새 시스템으로 마이그레이션된 이후의미래 능력을 더 잘 가늠할 수 있도록, 10월 31일까지 CPython 데모 저장소를 온라인에 올리는 것을 목표로 합니다]

이 제안은 CPython 개발 워크플로의 다양한 측면에 대한 개선 제안들을 다루는 Brett Cannon의 현재 평가의 일부입니다. 그 일정의 주요 날짜는 다음과 같습니다:

• 2월 1일: 초안 제안 게시(Kallithea의 경우 이 PEP)
• 4월 8일: Python Language Summit에서 최종 제안 논의
• 5월 1일: 브렛이 어느 제안을 채택할지 결정
• 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월에 새 서비스를 처음 채택할 때는(이 제안이 선정되고 제안된 파일럿 배포가 성공적일 경우) “바람직하지만 필수는 아닌” 것으로 간주됩니다:

• PSF가 호스팅하는 Kallithea 인스턴스에 대한 인증에 python-social-auth 사용을 허용
• 메인 Kallithea 저장소에 풀 리퀘스트를 제출할 때 GitHub와 BitBucket의 풀 리퀘스트 워크플로 사용을 허용
• Kallithea 호스팅 저장소와 풀 리퀘스트를 기반으로 강제 BuildBot 실행을 쉽게 트리거할 수 있도록 허용(PEP 462가 구현되기 전까지는 메인 CPython 저장소가 아닌 샌드박스 저장소에 사용할 것을 의도함)

CPython 핵심 개발에 대한 향후 영향

메인 CPython 개발 저장소에 대한 워크플로 요구 사항은 이 PEP에서 논의되는 저장소에 비해 훨씬 복잡합니다. 이러한 우려 사항은 PEP 462에서 더 자세히 다룹니다.

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

저는 또한 Pierre Yves-David와 함께 CPython 핵심 개발 워크플로의 일부 측면을 자동화하는 커스텀 Mercurial 확장을 개발하는 작업을 시작했습니다.

Copyright

This document has been placed in the public domain.