[Withdrawn] PEP 474 - Creating forge.python.org

원문 링크: PEP 474 - Creating forge.python.org

상태: Withdrawn 유형: Process 작성일: 19-Jul-2014

PEP 474 – forge.python.org 생성

개요

이 PEP (Python Enhancement Proposal)는 새로운 PSF(Python Software Foundation) 제공 리소스인 forge.python.org를 설정하여, 새로운 기여자(contributor)들이 더 쉽게 접근하고, 핵심 개발자(core developer)들이 관리하기 더 용이한 방식으로 다양한 지원 저장소(supporting repositories) (예: Python Enhancement Proposals 저장소)를 유지 관리하는 것을 제안합니다.

이 PEP는 CPython 자체의 핵심 개발 워크플로우에는 어떠한 변경도 제안하지 않습니다. (관련 내용은 PEP 462를 참조하십시오.)

PEP 철회

이 PEP는 저자에 의해 철회되었으며, GitLab 기반 제안인 PEP 507을 지지합니다. 만약 다른 사람이 이 PEP를 이어서 추진하고 싶다면, core-workflow 메일링 리스트에 연락하십시오.

제안

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

개별 저장소(예: 개발자 가이드 또는 PEP 저장소)는 기존 hg.python.org 인프라에서 새로운 forge.python.org 인프라로 개별적으로 마이그레이션될 수 있습니다. 각 마이그레이션은 hg.python.org에 읽기 전용 미러를 유지할지, 아니면 새 위치로 완전히 마이그레이션할지 결정해야 합니다.

hg.python.org에 읽기 전용 미러를 지원하는 것 외에도, forge.python.org는 GitHub 및 BitBucket과 같은 인기 있는 독점 호스팅 사이트에 미러를 호스팅하는 것도 목표로 합니다. 목표는 이들 사이트에 익숙한 사용자들이 선호하는 워크플로우를 사용하여 Pull Request를 제출하고 논의할 수 있도록 하고, forge.python.org가 이러한 기여(contribution)를 마스터 저장소로 자동으로 가져오도록 하는 것입니다.

상업적으로 지원되는 “오픈 소스 프로젝트를 위한 무료” 저장소 호스팅 서비스의 가용성과 인기를 고려할 때, 이것은 임의의 Python 프로젝트를 위한 일반적인 호스팅 사이트가 아닙니다. 초기 초점은 특히 CPython 및 현재 hg.python.org에서 호스팅되는 다른 저장소에 맞춰질 것입니다. 미래에는 python.org Django 애플리케이션의 저장소와 같이 현재 외부에서 호스팅되고 있는 다른 PSF 관리 저장소를 통합하여 Pull Request 기반 워크플로우에 접근할 수 있도록 확장될 가능성이 있습니다. 초기 마이그레이션과 마찬가지로, 이러한 미래의 마이그레이션도 각 저장소의 주요 사용자의 선호도를 고려하여 개별적으로 검토될 것입니다.

근거

현재 hg.python.org는 핵심 CPython 저장소뿐만 아니라, CPython 개발자 가이드 및 Python Enhancement Proposals와 같은 다른 저장소와 핵심 개발자 실험을 위한 다양한 “샌드박스(sandbox)” 저장소도 호스팅하고 있습니다.

GitHub 및 BitBucket과 같은 코드 호스팅 사이트에서 인기를 얻은 간단한 “Pull Request” 스타일 워크플로우는 다양한 CPython 릴리스의 병렬 유지 관리 및 개발에 필요한 복잡한 브랜칭 모델에는 적합하지 않지만, 독점 호스팅 사이트로 옮기고 싶지 않은 CPython 주변의 여러 보조 프로젝트에는 잘 맞습니다.

PSF에서 제공하는 소프트웨어 포지(forge)에 제안된 주요 요구 사항은 다음과 같습니다.

  • 간단한 “Pull Request” 스타일 워크플로우를 지원해야 합니다.
  • 간단한 변경을 위한 온라인 편집을 지원해야 합니다.
  • 활발한 개발 조직(커뮤니티 또는 상업)의 지원을 받아야 합니다.
  • 지속적인 비용 없이 PSF 인프라에 마스터 저장소의 자체 호스팅을 지원해야 합니다.

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

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

지속적인 비용 없이 자체 호스팅을 선호하는 것은 GitHub 및 BitBucket과 같은 “무료” 제공업체뿐만 아니라 다양한 독점 소스 코드 관리 서비스를 배제합니다.

Mercurial 지원에 대한 선호는 GitHub뿐만 아니라 GitLab 및 Gitorious와 같은 Git 전용 솔루션도 배제합니다.

온라인 편집 지원에 대한 엄격한 요구 사항은 Apache Allura/HgForge 조합을 배제합니다.

완전한 오픈 소스 솔루션에 대한 선호는 RhodeCode를 배제합니다.

이 제안의 저자가 고려한 다양한 옵션 중에서, Kallithea SCM이 forge.python.org 서비스의 제안된 기반으로 남습니다.

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

예상되는 이점

Kallithea를 forge.python.org로 배포하는 주요 이점은 개발자 가이드 및 PEP 저장소와 같은 지원 저장소를 Pull Request 및 온라인 편집을 사용하여 관리할 수 있다는 것입니다. 이는 다른 사용자가 제안한 업데이트를 적용하기 위해 PEP 편집자 및 다른 핵심 개발자들이 중개자 역할을 해야 하는 현재 워크플로우보다 훨씬 간단할 것입니다.

더 풍부한 관리 기능은 사용자에게 전체 설치에 대한 일반적인 접근 권한을 부여하지 않고도 협업 목적으로 특정 저장소에 대한 접근 권한을 부여하는 것을 훨씬 쉽게 만들 것입니다. 이는 핵심 개발자 접근 권한 부여와 관련된 전면적인 결정(all-or-nothing decision)이 아니라, 신뢰를 점진적으로 더 쉽게 부여하고 얻을 수 있게 함으로써 진입 장벽을 낮추는 데 도움이 됩니다.

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

현재 워크플로우에서도 CPython 자체는 세계에서 가장 큰 오픈 소스 프로젝트 중 하나입니다. 그러나 CPython의 워크플로우 인프라를 구성하는 프로젝트에 대한 기여를 장려하는 데는 훨씬 덜 효과적이었습니다.

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

이 접근 방식은 여러 가지 주요 이점을 제공하는 것을 목표로 합니다.

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

이러한 지속 가능한 엔지니어링 문제를 해결하기 위한 몇 가지 초기 단계가 이미 수행되었습니다.

  • Tymoteusz Jankowski는 Donald Stufft와 함께 PSF의 Salt 기반 인프라 자동화를 사용하여 Kallithea를 배포하는 데 필요한 작업을 논의했습니다.
  • Graham Dumpleton과 저자는 Red Hat의 오픈 소스 호스팅 서비스인 OpenShift Online의 무료 티어에 데모 Kallithea 인스턴스를 쉽게 배포하는 작업을 진행했습니다.

다음 주요 단계는 Windows, Mac OS X 및 Linux의 기여자(contributor)가 자신의 시스템 작동에 방해받지 않고 Kallithea 테스트를 로컬에서 실행할 수 있는 로컬 개발 워크플로우를 고안하는 것입니다. 현재 계획된 접근 방식은 테스트 목적으로 로컬 VM을 실행하는 개발자를 위해 특별히 고안된 인기 있는 자동화된 가상 머신 관리 시스템인 Vagrant에 중점을 두는 것입니다.

이러한 워크플로우 제안이 Kallithea에 잘 작동한다면, Roundup, BuildBot, 그리고 주요 python.org 웹사이트를 포함한 다른 PSF 및 CPython 인프라 서비스를 지원하는 업스트림 프로젝트에서도 사용을 제안할 가치가 있을 수 있습니다.

개인적인 동기

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

특히 코드 검토(code review) 워크플로우와 관련하여, 제가 경력 동안 사용한 주요 코드 검토 워크플로우 관리 도구는 Gerrit (세분화된 접근 제어 기능을 갖춘 다단계 코드 검토용), GitHub 및 BitBucket (기본 Pull Request 기반 워크플로우용), 그리고 Rietveld (CPython의 선택적 사전 커밋 검토용)입니다.

Kallithea는 현재 저장소 호스팅 및 코드 검토 관리 플랫폼을 결합한 프로젝트이지만, 온라인 병합을 제공함으로써 둘을 직접 통합하지는 않습니다. 이는 GitHub/BitBucket Pull Request 모델의 낮은 진입 장벽 이점과 Gerrit의 멘토링 및 작업 인계 이점을 Kallithea에 대한 온라인 코드 병합 모델을 정의하는 데 업스트림 Kallithea 개발자들과 협력하여 융합할 기회를 만듭니다.

기술적 우려 사항 및 과제

CPython 인프라에 새로운 서비스를 도입하는 것은 여러 가지 흥미로운 기술적 우려 사항과 과제를 제시합니다. 이 섹션에서는 가장 중요한 몇 가지를 다룹니다.

서비스 호스팅

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

그러나 다른 호스팅 옵션도 고려될 것입니다. 특히 Google Container Engine 또는 Red Hat OpenShift Online 서비스의 차세대 버전에서 Kubernetes 호스팅 웹 서비스로 배포될 가능성이 있으며, GCEPersistentDisk 또는 오픈 소스 GlusterFS 분산 파일 시스템을 사용하여 소스 코드 저장소를 보관하는 방안도 있습니다.

지속적인 인프라 유지 관리

지속적인 인프라 유지 관리는 PSF 내에서 우려되는 영역입니다. 현재 Fedora Infrastructure Apprentice 또는 GNOME Infrastructure Apprentice 프로그램과 동등한 시스템 관리자 멘토십 프로그램이 부족하기 때문입니다.

대신 시스템은 주로 개발자들이 개발 관련 기여 외에 파트타임 활동으로 유지 관리하는 경향이 있습니다. 이는 개발(새로운 기능을 제공하거나 더 나은 사용자 경험을 제공하거나 기존 문제를 해결하기 위해 서비스를 변경하는 것)보다 운영(기존 시스템을 잘 작동시키는 것)에 더 관심 있는 사람들을 모집하는 대신입니다.

저는 미래에 PSF가 그러한 프로그램을 운영하기를 개인적으로 바라지만, 그러한 프로그램을 설정하는 것이 실현 가능한 단기 목표라고 생각하지 않습니다. 그러나 OpenStack 및 Salt와 같은 현대적인 인프라 기술의 PSF 기존 사용을 더 많은 서비스로 확장하고 컨테이너 및 컨테이너 플랫폼의 잠재적 이점을 탐색하기 시작함으로써 그러한 프로그램의 기반을 계속 마련하는 것은 실현 가능하다고 생각합니다.

또한 ManageIQ와 같은 오픈 소스 클라우드 관리 플랫폼이 Rackspace, Google, Amazon 및 기타 서비스 전반에 걸쳐 발생하는 “클라우드 확산” 문제를 더 잘 제어하는 데 도움이 될 수 있는지 여부에 대해서도 알아볼 계획입니다.

사용자 계정 관리

이상적으로는 Kallithea, Roundup/Rietveld, PyPI 및 새로운 python.org 사이트의 백엔드를 포함한 모든 python.org 서비스에 걸쳐 단일 계정을 제공할 수 있기를 원합니다. 그러나 실제로 이를 구현하는 것은 이 PEP와는 별개의 인프라 프로젝트가 될 것입니다.

forge.python.org의 초기 출시를 위해 PSF 인프라 내에 또 다른 ID 사일로(identity silo)를 만들 가능성이 높습니다. 잠재적으로 더 나은 대안은 Kallithea에 python-social-auth 지원을 추가하는 것이지만, 실제로 그렇게 하는 것은 서비스의 초기 출시를 위한 요구 사항은 아닙니다. (주요 기술적 우려 사항은 Kallithea가 아직 Pyramid로 포팅되지 않은 Pylons 애플리케이션이므로, 통합을 위해서는 python-social-auth에 Pylons 백엔드를 추가하거나 Kallithea에서 Pyramid 마이그레이션을 시작해야 한다는 것입니다).

Mercurial 저장소에 대한 기존 SSH 접근 및 링크 끊김

이 PEP는 기존 hg.python.org 설치를 그대로 두고, 새로운 호스트에 Kallithea를 설정할 것을 제안합니다. 이 접근 방식은 CPython 자체의 개발(및 새 소프트웨어 포지로 마이그레이션하지 않는 다른 프로젝트)을 방해할 위험을 최소화하지만, 기존 저장소의 마이그레이션을 더 혼란스럽게 만듭니다 (기존 체크아웃이 중단되기 때문입니다).

Roundup과의 통합

Kallithea는 구성 가능한 이슈 트래커(issue tracker) 통합을 제공합니다. 이는 forge.python.org 서비스의 초기 출시 전에 bugs.python.org의 Roundup 이슈 트래커와 통합되도록 적절하게 설정되어야 합니다.

GitHub 및 BitBucket에서 Pull Request 수락

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

외부 서비스에서 Pull Request를 수락하고, 이를 forge.python.org의 마스터 저장소로 제출하는 것으로 미러링하는 것은 매우 바람직한 기능이지만, 더 복잡한 문제이며 forge.python.org 서비스의 초기 출시에는 포함되지 않을 가능성이 높습니다.

투명한 Git 및 Mercurial 상호 운용성

Kallithea의 Git 및 Mercurial 모두에 대한 기본 지원은 개발자가 forge.python.org에 호스팅된 저장소와 상호 작용하기 위해 선호하는 클라이언트를 사용하는 것을 비교적 간단하게 만들 수 있는 기회를 제공합니다.

이러한 투명한 상호 운용성은 아직 존재하지 않지만, 자체 다중-VCS(Version Control System) 저장소 호스팅 서비스를 운영함으로써, 상업적 이익이 아닐 가능성이 있는 기능을 제공하기 위해 독점 제공업체를 수동적으로 기다리는 대신, 이 기능을 현실화할 기회를 제공합니다. 오픈 소스 커뮤니티와 상업 제공업체 간에는 이 특정 영역에서 인센티브의 상당한 불일치가 있습니다. VCS 클라이언트 선택을 제공하는 것이 잠재적 기여자에게 특정 도구 선택을 강요하는 독단적인 결정을 프로젝트가 할 필요성을 없앰으로써 커뮤니션 마찰을 크게 줄일 수 있음에도 불구하고, 개발자 선호도와 관계없이 도구 선택을 위에서 아래로 강제하는 것이 현재 GitHub 및 Atlassian의 유료 고객을 생산하는 기업 및 기타 조직 환경에서 여전히 표준입니다.

수락 전에 투명한 상호 운용성이 없는 경우, 이 PEP는 forge.python.org에 호스팅된 Mercurial 저장소에 대한 Pull Request를 생성하기 위한 Git 사용자용 CPython 개발자 가이드 섹션에 포함될 특정 권장 사항을 제안해야 합니다.

파일럿 목표 및 타임라인

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

  • 2월 1일: 제안 초안 발행 (Kallithea의 경우, 이 PEP)
  • 4월 8일: Python Language Summit에서 최종 제안 논의
  • 5월 1일: Brett의 제안 수락 결정
  • 9월 13일: Python 3.5 릴리스, Python 3.6에 새로운 워크플로우 채택

이 제안이 추가 개발을 위해 선택되면, 다음 파일럿 배포(pilot deployment)부터 시작할 것을 제안합니다.

  • 최소한 개발자 가이드 및 PEP 저장소를 포함하는 kallithea-pilot.python.org에서 운영되는 참조 구현. 이는 “일회용(throwaway)” 인스턴스로, 핵심 개발자 및 다른 기여자(contributor)들이 저장소 히스토리에 대한 장기적인 결과에 대해 걱정하지 않고 자유롭게 실험할 수 있도록 합니다.
  • GitHub 및 BitBucket에 Kallithea 호스팅 저장소의 읽기 전용 라이브 미러. 파일럿 서비스 자체와 마찬가지로, 이들은 파일럿 기간 종료 후 폐기될 임시 저장소입니다.
  • 이러한 미러를 사용하여 Kallithea 호스팅 Mercurial 저장소에 대한 Pull Request를 생성하는 방법에 대한 명확한 문서.
  • 코드 검토 댓글 및 커밋 메시지의 이슈 참조를 bugs.python.org의 해당 이슈에 자동으로 연결.
  • Kallithea 기반 PEP 편집 및 제출 워크플로우를 설명하는 PEP 1에 대한 초안 업데이트.

다음 항목들은 프로덕션 마이그레이션에 필요하지만, 파일럿의 일부로 업데이트된 구현을 시도할 명확한 방법은 없는 것으로 보입니다.

  • PEP 게시 프로세스 및 개발자 가이드 게시 프로세스를 재배치된 Mercurial 저장소를 기반으로 조정.

다음 항목들은 전체 워크플로우 개선 프로세스의 목표가 되겠지만, 9월에 새 서비스를 초기 채택하는 데 “바람직하지만 필수는 아님”으로 간주됩니다 (이 제안이 선택되고 제안된 파일럿 배포가 성공적인 경우).

  • python-social-auth를 사용하여 PSF 호스팅 Kallithea 인스턴스에 대한 인증 허용.
  • GitHub 및 BitBucket Pull Request 워크플로우를 사용하여 주 Kallithea 저장소에 Pull Request 제출 허용.
  • Kallithea 호스팅 저장소 및 Pull Request를 기반으로 BuildBot 실행을 쉽게 트리거 허용 (PEP 462 구현 전에는 주 CPython 저장소보다는 샌드박스 저장소와 함께 사용하기 위한 것임).

CPython 핵심 개발에 대한 미래 영향

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

Guido의 권고에 따라 Rietveld를 더 활발하게 유지 관리되는 코드 검토 시스템으로 교체하기 위해, 현재 제 계획은 그 PEP를 Kallithea를 제안된 접착 계층(glue layer)으로 사용하여 다시 작성하고, 향상된 Kallithea Pull Request가 궁극적으로 이슈 트래커에 패치 파일을 직접 업로드하는 현재 관행을 대체하는 것입니다.

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

저작권

이 문서는 퍼블릭 도메인에 공개되었습니다.

PEP 474 – forge.python.org 생성

개요

이 PEP (Python Enhancement Proposal)는 새로운 PSF(Python Software Foundation) 제공 리소스인 forge.python.org를 설정하여, 새로운 기여자(contributor)들이 더 쉽게 접근하고, 핵심 개발자(core developer)들이 관리하기 더 용이한 방식으로 다양한 지원 저장소(supporting repositories) (예: Python Enhancement Proposals 저장소)를 유지 관리하는 것을 제안합니다.

이 PEP는 CPython 자체의 핵심 개발 워크플로우에는 어떠한 변경도 제안하지 않습니다. (관련 내용은 PEP 462를 참조하십시오.)

PEP 철회

이 PEP는 저자에 의해 철회되었으며, GitLab 기반 제안인 PEP 507을 지지합니다. 만약 다른 사람이 이 PEP를 이어서 추진하고 싶다면, core-workflow 메일링 리스트에 연락하십시오.

제안

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

개별 저장소(예: 개발자 가이드 또는 PEP 저장소)는 기존 hg.python.org 인프라에서 새로운 forge.python.org 인프라로 개별적으로 마이그레이션될 수 있습니다. 각 마이그레이션은 hg.python.org에 읽기 전용 미러를 유지할지, 아니면 새 위치로 완전히 마이그레이션할지 결정해야 합니다.

hg.python.org에 읽기 전용 미러를 지원하는 것 외에도, forge.python.org는 GitHub 및 BitBucket과 같은 인기 있는 독점 호스팅 사이트에 미러를 호스팅하는 것도 목표로 합니다. 목표는 이들 사이트에 익숙한 사용자들이 선호하는 워크플로우를 사용하여 Pull Request를 제출하고 논의할 수 있도록 하고, forge.python.org가 이러한 기여(contribution)를 마스터 저장소로 자동으로 가져오도록 하는 것입니다.

상업적으로 지원되는 “오픈 소스 프로젝트를 위한 무료” 저장소 호스팅 서비스의 가용성과 인기를 고려할 때, 이것은 임의의 Python 프로젝트를 위한 일반적인 호스팅 사이트가 아닙니다. 초기 초점은 특히 CPython 및 현재 hg.python.org에서 호스팅되는 다른 저장소에 맞춰질 것입니다. 미래에는 python.org Django 애플리케이션의 저장소와 같이 현재 외부에서 호스팅되고 있는 다른 PSF 관리 저장소를 통합하여 Pull Request 기반 워크플로우에 접근할 수 있도록 확장될 가능성이 있습니다. 초기 마이그레이션과 마찬가지로, 이러한 미래의 마이그레이션도 각 저장소의 주요 사용자의 선호도를 고려하여 개별적으로 검토될 것입니다.

근거

현재 hg.python.org는 핵심 CPython 저장소뿐만 아니라, CPython 개발자 가이드 및 Python Enhancement Proposals와 같은 다른 저장소와 핵심 개발자 실험을 위한 다양한 “샌드박스(sandbox)” 저장소도 호스팅하고 있습니다.

GitHub 및 BitBucket과 같은 코드 호스팅 사이트에서 인기를 얻은 간단한 “Pull Request” 스타일 워크플로우는 다양한 CPython 릴리스의 병렬 유지 관리 및 개발에 필요한 복잡한 브랜칭 모델에는 적합하지 않지만, 독점 호스팅 사이트로 옮기고 싶지 않은 CPython 주변의 여러 보조 프로젝트에는 잘 맞습니다.

PSF에서 제공하는 소프트웨어 포지(forge)에 제안된 주요 요구 사항은 다음과 같습니다.

  • 간단한 “Pull Request” 스타일 워크플로우를 지원해야 합니다.
  • 간단한 변경을 위한 온라인 편집을 지원해야 합니다.
  • 활발한 개발 조직(커뮤니티 또는 상업)의 지원을 받아야 합니다.
  • 지속적인 비용 없이 PSF 인프라에 마스터 저장소의 자체 호스팅을 지원해야 합니다.

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

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

지속적인 비용 없이 자체 호스팅을 선호하는 것은 GitHub 및 BitBucket과 같은 “무료” 제공업체뿐만 아니라 다양한 독점 소스 코드 관리 서비스를 배제합니다.

Mercurial 지원에 대한 선호는 GitHub뿐만 아니라 GitLab 및 Gitorious와 같은 Git 전용 솔루션도 배제합니다.

온라인 편집 지원에 대한 엄격한 요구 사항은 Apache Allura/HgForge 조합을 배제합니다.

완전한 오픈 소스 솔루션에 대한 선호는 RhodeCode를 배제합니다.

이 제안의 저자가 고려한 다양한 옵션 중에서, Kallithea SCM이 forge.python.org 서비스의 제안된 기반으로 남습니다.

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

예상되는 이점

Kallithea를 forge.python.org로 배포하는 주요 이점은 개발자 가이드 및 PEP 저장소와 같은 지원 저장소를 Pull Request 및 온라인 편집을 사용하여 관리할 수 있다는 것입니다. 이는 다른 사용자가 제안한 업데이트를 적용하기 위해 PEP 편집자 및 다른 핵심 개발자들이 중개자 역할을 해야 하는 현재 워크플로우보다 훨씬 간단할 것입니다.

더 풍부한 관리 기능은 사용자에게 전체 설치에 대한 일반적인 접근 권한을 부여하지 않고도 협업 목적으로 특정 저장소에 대한 접근 권한을 부여하는 것을 훨씬 쉽게 만들 것입니다. 이는 핵심 개발자 접근 권한 부여와 관련된 전면적인 결정(all-or-nothing decision)이 아니라, 신뢰를 점진적으로 더 쉽게 부여하고 얻을 수 있게 함으로써 진입 장벽을 낮추는 데 도움이 됩니다.

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

현재 워크플로우에서도 CPython 자체는 세계에서 가장 큰 오픈 소스 프로젝트 중 하나입니다. 그러나 CPython의 워크플로우 인프라를 구성하는 프로젝트에 대한 기여를 장려하는 데는 훨씬 덜 효과적이었습니다.

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

이 접근 방식은 여러 가지 주요 이점을 제공하는 것을 목표로 합니다.

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

이러한 지속 가능한 엔지니어링 문제를 해결하기 위한 몇 가지 초기 단계가 이미 수행되었습니다.

  • Tymoteusz Jankowski는 Donald Stufft와 함께 PSF의 Salt 기반 인프라 자동화를 사용하여 Kallithea를 배포하는 데 필요한 작업을 논의했습니다.
  • Graham Dumpleton과 저자는 Red Hat의 오픈 소스 호스팅 서비스인 OpenShift Online의 무료 티어에 데모 Kallithea 인스턴스를 쉽게 배포하는 작업을 진행했습니다.

다음 주요 단계는 Windows, Mac OS X 및 Linux의 기여자(contributor)가 자신의 시스템 작동에 방해받지 않고 Kallithea 테스트를 로컬에서 실행할 수 있는 로컬 개발 워크플로우를 고안하는 것입니다. 현재 계획된 접근 방식은 테스트 목적으로 로컬 VM을 실행하는 개발자를 위해 특별히 고안된 인기 있는 자동화된 가상 머신 관리 시스템인 Vagrant에 중점을 두는 것입니다.

이러한 워크플로우 제안이 Kallithea에 잘 작동한다면, Roundup, BuildBot, 그리고 주요 python.org 웹사이트를 포함한 다른 PSF 및 CPython 인프라 서비스를 지원하는 업스트림 프로젝트에서도 사용을 제안할 가치가 있을 수 있습니다.

개인적인 동기

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

특히 코드 검토(code review) 워크플로우와 관련하여, 제가 경력 동안 사용한 주요 코드 검토 워크플로우 관리 도구는 Gerrit (세분화된 접근 제어 기능을 갖춘 다단계 코드 검토용), GitHub 및 BitBucket (기본 Pull Request 기반 워크플로우용), 그리고 Rietveld (CPython의 선택적 사전 커밋 검토용)입니다.

Kallithea는 현재 저장소 호스팅 및 코드 검토 관리 플랫폼을 결합한 프로젝트이지만, 온라인 병합을 제공함으로써 둘을 직접 통합하지는 않습니다. 이는 GitHub/BitBucket Pull Request 모델의 낮은 진입 장벽 이점과 Gerrit의 멘토링 및 작업 인계 이점을 Kallithea에 대한 온라인 코드 병합 모델을 정의하는 데 업스트림 Kallithea 개발자들과 협력하여 융합할 기회를 만듭니다.

기술적 우려 사항 및 과제

CPython 인프라에 새로운 서비스를 도입하는 것은 여러 가지 흥미로운 기술적 우려 사항과 과제를 제시합니다. 이 섹션에서는 가장 중요한 몇 가지를 다룹니다.

서비스 호스팅

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

그러나 다른 호스팅 옵션도 고려될 것입니다. 특히 Google Container Engine 또는 Red Hat OpenShift Online 서비스의 차세대 버전에서 Kubernetes 호스팅 웹 서비스로 배포될 가능성이 있으며, GCEPersistentDisk 또는 오픈 소스 GlusterFS 분산 파일 시스템을 사용하여 소스 코드 저장소를 보관하는 방안도 있습니다.

지속적인 인프라 유지 관리

지속적인 인프라 유지 관리는 PSF 내에서 우려되는 영역입니다. 현재 Fedora Infrastructure Apprentice 또는 GNOME Infrastructure Apprentice 프로그램과 동등한 시스템 관리자 멘토십 프로그램이 부족하기 때문입니다.

대신 시스템은 주로 개발자들이 개발 관련 기여 외에 파트타임 활동으로 유지 관리하는 경향이 있습니다. 이는 개발(새로운 기능을 제공하거나 더 나은 사용자 경험을 제공하거나 기존 문제를 해결하기 위해 서비스를 변경하는 것)보다 운영(기존 시스템을 잘 작동시키는 것)에 더 관심 있는 사람들을 모집하는 대신입니다.

저는 미래에 PSF가 그러한 프로그램을 운영하기를 개인적으로 바라지만, 그러한 프로그램을 설정하는 것이 실현 가능한 단기 목표라고 생각하지 않습니다. 그러나 OpenStack 및 Salt와 같은 현대적인 인프라 기술의 PSF 기존 사용을 더 많은 서비스로 확장하고 컨테이너 및 컨테이너 플랫폼의 잠재적 이점을 탐색하기 시작함으로써 그러한 프로그램의 기반을 계속 마련하는 것은 실현 가능하다고 생각합니다.

또한 ManageIQ와 같은 오픈 소스 클라우드 관리 플랫폼이 Rackspace, Google, Amazon 및 기타 서비스 전반에 걸쳐 발생하는 “클라우드 확산” 문제를 더 잘 제어하는 데 도움이 될 수 있는지 여부에 대해서도 알아볼 계획입니다.

사용자 계정 관리

이상적으로는 Kallithea, Roundup/Rietveld, PyPI 및 새로운 python.org 사이트의 백엔드를 포함한 모든 python.org 서비스에 걸쳐 단일 계정을 제공할 수 있기를 원합니다. 그러나 실제로 이를 구현하는 것은 이 PEP와는 별개의 인프라 프로젝트가 될 것입니다.

forge.python.org의 초기 출시를 위해 PSF 인프라 내에 또 다른 ID 사일로(identity silo)를 만들 가능성이 높습니다. 잠재적으로 더 나은 대안은 Kallithea에 python-social-auth 지원을 추가하는 것이지만, 실제로 그렇게 하는 것은 서비스의 초기 출시를 위한 요구 사항은 아닙니다. (주요 기술적 우려 사항은 Kallithea가 아직 Pyramid로 포팅되지 않은 Pylons 애플리케이션이므로, 통합을 위해서는 python-social-auth에 Pylons 백엔드를 추가하거나 Kallithea에서 Pyramid 마이그레이션을 시작해야 한다는 것입니다).

Mercurial 저장소에 대한 기존 SSH 접근 및 링크 끊김

이 PEP는 기존 hg.python.org 설치를 그대로 두고, 새로운 호스트에 Kallithea를 설정할 것을 제안합니다. 이 접근 방식은 CPython 자체의 개발(및 새 소프트웨어 포지로 마이그레이션하지 않는 다른 프로젝트)을 방해할 위험을 최소화하지만, 기존 저장소의 마이그레이션을 더 혼란스럽게 만듭니다 (기존 체크아웃이 중단되기 때문입니다).

Roundup과의 통합

Kallithea는 구성 가능한 이슈 트래커(issue tracker) 통합을 제공합니다. 이는 forge.python.org 서비스의 초기 출시 전에 bugs.python.org의 Roundup 이슈 트래커와 통합되도록 적절하게 설정되어야 합니다.

GitHub 및 BitBucket에서 Pull Request 수락

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

외부 서비스에서 Pull Request를 수락하고, 이를 forge.python.org의 마스터 저장소로 제출하는 것으로 미러링하는 것은 매우 바람직한 기능이지만, 더 복잡한 문제이며 forge.python.org 서비스의 초기 출시에는 포함되지 않을 가능성이 높습니다.

투명한 Git 및 Mercurial 상호 운용성

Kallithea의 Git 및 Mercurial 모두에 대한 기본 지원은 개발자가 forge.python.org에 호스팅된 저장소와 상호 작용하기 위해 선호하는 클라이언트를 사용하는 것을 비교적 간단하게 만들 수 있는 기회를 제공합니다.

이러한 투명한 상호 운용성은 아직 존재하지 않지만, 자체 다중-VCS(Version Control System) 저장소 호스팅 서비스를 운영함으로써, 상업적 이익이 아닐 가능성이 있는 기능을 제공하기 위해 독점 제공업체를 수동적으로 기다리는 대신, 이 기능을 현실화할 기회를 제공합니다. 오픈 소스 커뮤니티와 상업 제공업체 간에는 이 특정 영역에서 인센티브의 상당한 불일치가 있습니다. VCS 클라이언트 선택을 제공하는 것이 잠재적 기여자에게 특정 도구 선택을 강요하는 독단적인 결정을 프로젝트가 할 필요성을 없앰으로써 커뮤니션 마찰을 크게 줄일 수 있음에도 불구하고, 개발자 선호도와 관계없이 도구 선택을 위에서 아래로 강제하는 것이 현재 GitHub 및 Atlassian의 유료 고객을 생산하는 기업 및 기타 조직 환경에서 여전히 표준입니다.

수락 전에 투명한 상호 운용성이 없는 경우, 이 PEP는 forge.python.org에 호스팅된 Mercurial 저장소에 대한 Pull Request를 생성하기 위한 Git 사용자용 CPython 개발자 가이드 섹션에 포함될 특정 권장 사항을 제안해야 합니다.

파일럿 목표 및 타임라인

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

  • 2월 1일: 제안 초안 발행 (Kallithea의 경우, 이 PEP)
  • 4월 8일: Python Language Summit에서 최종 제안 논의
  • 5월 1일: Brett의 제안 수락 결정
  • 9월 13일: Python 3.5 릴리스, Python 3.6에 새로운 워크플로우 채택

이 제안이 추가 개발을 위해 선택되면, 다음 파일럿 배포(pilot deployment)부터 시작할 것을 제안합니다.

  • 최소한 개발자 가이드 및 PEP 저장소를 포함하는 kallithea-pilot.python.org에서 운영되는 참조 구현. 이는 “일회용(throwaway)” 인스턴스로, 핵심 개발자 및 다른 기여자(contributor)들이 저장소 히스토리에 대한 장기적인 결과에 대해 걱정하지 않고 자유롭게 실험할 수 있도록 합니다.
  • GitHub 및 BitBucket에 Kallithea 호스팅 저장소의 읽기 전용 라이브 미러. 파일럿 서비스 자체와 마찬가지로, 이들은 파일럿 기간 종료 후 폐기될 임시 저장소입니다.
  • 이러한 미러를 사용하여 Kallithea 호스팅 Mercurial 저장소에 대한 Pull Request를 생성하는 방법에 대한 명확한 문서.
  • 코드 검토 댓글 및 커밋 메시지의 이슈 참조를 bugs.python.org의 해당 이슈에 자동으로 연결.
  • Kallithea 기반 PEP 편집 및 제출 워크플로우를 설명하는 PEP 1에 대한 초안 업데이트.

다음 항목들은 프로덕션 마이그레이션에 필요하지만, 파일럿의 일부로 업데이트된 구현을 시도할 명확한 방법은 없는 것으로 보입니다.

  • PEP 게시 프로세스 및 개발자 가이드 게시 프로세스를 재배치된 Mercurial 저장소를 기반으로 조정.

다음 항목들은 전체 워크플로우 개선 프로세스의 목표가 되겠지만, 9월에 새 서비스를 초기 채택하는 데 “바람직하지만 필수는 아님”으로 간주됩니다 (이 제안이 선택되고 제안된 파일럿 배포가 성공적인 경우).

  • python-social-auth를 사용하여 PSF 호스팅 Kallithea 인스턴스에 대한 인증 허용.
  • GitHub 및 BitBucket Pull Request 워크플로우를 사용하여 주 Kallithea 저장소에 Pull Request 제출 허용.
  • Kallithea 호스팅 저장소 및 Pull Request를 기반으로 BuildBot 실행을 쉽게 트리거 허용 (PEP 462 구현 전에는 주 CPython 저장소보다는 샌드박스 저장소와 함께 사용하기 위한 것임).

CPython 핵심 개발에 대한 미래 영향

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

Guido의 권고에 따라 Rietveld를 더 활발하게 유지 관리되는 코드 검토 시스템으로 교체하기 위해, 현재 제 계획은 그 PEP를 Kallithea를 제안된 접착 계층(glue layer)으로 사용하여 다시 작성하고, 향상된 Kallithea Pull Request가 궁극적으로 이슈 트래커에 패치 파일을 직접 업로드하는 현재 관행을 대체하는 것입니다.

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

저작권

이 문서는 퍼블릭 도메인에 공개되었습니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments