Zusammenfassung

Dieser PEP schlägt die Einrichtung einer neuen, von der PSF bereitgestellten Ressource, forge.python.org, als Ort für die Pflege verschiedener unterstützender Repositories (wie z. B. des Repositories für Python Enhancement Proposals) vor, um sie für neue Mitwirkende zugänglicher und für Kernentwickler einfacher zu verwalten.

Dieser PEP schlägt keine Änderungen am Kernentwicklungs-Workflow von CPython selbst vor (siehe PEP 462 in Bezug darauf).

Rücknahme eines PEP

Dieser PEP wurde vom Autor zurückgezogen zugunsten des GitLab-basierten Vorschlags in PEP 507.

Wenn jemand anderes die Patenschaft für diesen PEP übernehmen möchte, kontaktieren Sie die Mailingliste core-workflow

Vorschlag

Dieser PEP schlägt vor, eine Instanz des selbst gehosteten Code-Repository-Managementsystems Kallithea als „forge.python.org“ bereitzustellen.

Einzelne Repositories (wie z. B. das Entwicklerhandbuch oder das PEP-Repository) können dann von der bestehenden hg.python.org-Infrastruktur auf die neue forge.python.org-Infrastruktur migriert werden, und zwar von Fall zu Fall. Bei jeder Migration muss entschieden werden, ob ein schreibgeschützter Spiegel auf hg.python.org beibehalten werden soll oder ob die Migration komplett an den neuen Standort erfolgen soll.

Zusätzlich zur Unterstützung von schreibgeschützten Spiegeln auf hg.python.org zielt forge.python.org auch darauf ab, Spiegel auf beliebten proprietären Hosting-Seiten wie GitHub und BitBucket zu hosten. Ziel ist es, Benutzern, die mit diesen Seiten vertraut sind, das Einreichen und Diskutieren von Pull-Anfragen über ihren bevorzugten Workflow zu ermöglichen, wobei forge.python.org diese Beiträge automatisch in das Haupt-Repository überträgt.

Angesichts der Verfügbarkeit und Beliebtheit von kommerziell unterstützten „kostenlosen für Open-Source-Projekte“-Repository-Hosting-Diensten wäre dies keine allgemeine Hosting-Site für beliebige Python-Projekte. Der anfängliche Fokus liegt speziell auf CPython und anderen Repositories, die derzeit auf hg.python.org gehostet werden. In Zukunft könnte dies potenziell auf die Konsolidierung anderer von der PSF verwalteter Repositories erweitert werden, die derzeit extern gehostet werden, um Zugang zu einem Pull-Request-basierten Workflow zu erhalten, wie z. B. das Repository für die python.org Django-Anwendung. Wie bei den anfänglichen Migrationen würden zukünftige Migrationen von Fall zu Fall betrachtet, wobei die Präferenzen der Hauptnutzer jedes Repositorys berücksichtigt werden.

Begründung

Derzeit hostet hg.python.org mehr als nur das Kern-CPython-Repository. Es hostet auch andere Repositories wie die für das CPython-Entwicklerhandbuch und für Python Enhancement Proposals sowie verschiedene „Sandbox“-Repositories für Experimente von Kernentwicklern.

Obwohl der einfache „Pull Request“-Workflow, der durch Code-Hosting-Seiten wie GitHub und BitBucket populär geworden ist, für das komplexe Branching-Modell, das für die parallele Wartung und Entwicklung der verschiedenen CPython-Releases erforderlich ist, nicht ausreichend ist, passt er gut zu mehreren der Nebenprojekte, die CPython umgeben und die wir nicht auf eine proprietäre Hosting-Site verschieben möchten.

Die wichtigsten Anforderungen, die für eine von der PSF bereitgestellte Software-Forge vorgeschlagen werden, sind:

• MUSS einfache „Pull Request“-Workflows unterstützen
• MUSS die Online-Bearbeitung für einfache Änderungen unterstützen
• MUSS von einer aktiven Entwicklungsorganisation (gemeinschaftlich oder kommerziell) unterstützt werden
• MUSS das Self-Hosting des Haupt-Repositorys auf der PSF-Infrastruktur ohne laufende Gebühren unterstützen

Zusätzliche empfohlene Anforderungen, die von diesem Vorschlag erfüllt werden, aber verhandelbar sein können, wenn eine ausreichend überzeugende Alternative vorgestellt wird

• SOLLTE eine vollständig Open-Source-Anwendung sein, die in Python geschrieben ist
• SOLLTE Mercurial unterstützen (zur Konsistenz mit bestehenden Tools)
• SOLLTE Git unterstützen (um diese Option für Benutzer bereitzustellen, die sie bevorzugen)
• SOLLTE Benutzern von Git- und Mercurial-Clients ermöglichen, transparent an demselben Repository zusammenzuarbeiten
• SOLLTE Benutzern von GitHub und BitBucket ermöglichen, vorgeschlagene Änderungen über die Standard-Pull-Request-Workflows dieser Tools einzureichen
• SOLLTE offen für Anpassungen sein, um den Bedürfnissen der CPython-Kernentwicklung gerecht zu werden, einschließlich der Bereitstellung eines potenziellen Weges für die vorgeschlagene Migration zu einem Core-Reviewer-Modell in PEP 462

Die Bevorzugung des Self-Hostings ohne laufende Gebühren schließt die „Free-as-in-beer“-Anbieter wie GitHub und BitBucket aus, zusätzlich zu den verschiedenen proprietären Source-Code-Management-Angeboten.

Die Bevorzugung der Mercurial-Unterstützung schließt nicht nur GitHub aus, sondern auch andere reine Git-Lösungen wie GitLab und Gitorious.

Die harte Anforderung der Online-Bearbeitungsunterstützung schließt die Kombination Apache Allura/HgForge aus.

Die Bevorzugung einer vollständig Open-Source-Lösung schließt RhodeCode aus.

Von den verschiedenen Optionen, die vom Autor dieses Vorschlags in Betracht gezogen wurden, bleibt Kallithea SCM als Grundlage für einen forge.python.org-Service übrig.

Kallithea ist eine vollständige GPLv3-Anwendung (abgeleitet von den klar und unmissverständlich unter GPLv3 lizenzierten Komponenten von RhodeCode), die unter der Schirmherrschaft der Software Freedom Conservancy entwickelt wird. Die Conservancy hat bestätigt, dass die Kallithea-Codebasis vollständig und gültig unter GPLv3 lizenziert ist. Neben ihrer Rolle beim Aufbau der anfänglichen Kallithea-Community ist die Conservancy auch die rechtliche Heimat der Projekte Mercurial und Git. Andere SFC-Mitgliedsprojekte, die Python-Benutzern vertraut sein mögen, sind Twisted, Gevent, BuildBot und PyPy.

Angestrebte Vorteile

Der Hauptvorteil der Bereitstellung von Kallithea als forge.python.org besteht darin, dass unterstützende Repositories wie das Entwicklerhandbuch und das PEP-Repo potenziell mit Pull-Anfragen und Online-Bearbeitung verwaltet werden könnten. Dies wäre wesentlich einfacher als der aktuelle Workflow, der PEP-Editoren und andere Kernentwickler dazu zwingt, als Vermittler zu fungieren, um von anderen Benutzern vorgeschlagene Aktualisierungen anzuwenden.

Die reichhaltigere administrative Funktionalität würde es auch wesentlich einfacher machen, Benutzern Zugriff auf bestimmte Repositories zu gewähren, um zusammenzuarbeiten, ohne ihnen allgemeinen Zugriff auf die gesamte Installation gewähren zu müssen. Dies senkt die Eintrittsbarrieren, da Vertrauen leichter und inkrementell gewährt und verdient werden kann, anstatt eine Alles-oder-Nichts-Entscheidung über die Gewährung des Zugangs als Kernentwickler zu treffen.

Überlegungen zur Wartungstechnik

Selbst mit seinem aktuellen Workflow bleibt CPython eines der größten Open-Source-Projekte der Welt (in den Top 2% der auf OpenHub verfolgten Projekte). Leider waren wir deutlich weniger effektiv darin, Beiträge zu den Projekten zu fördern, aus denen die Workflow-Infrastruktur von CPython besteht, einschließlich der Sicherstellung, dass unsere Installationen dem Upstream folgen und dass unsere eigenen Anpassungen, wo immer dies möglich ist, dem Originalprojekt zurückgegeben werden.

Daher ist ein Kernbestandteil dieses Vorschlags, aktiv mit der Upstream-Kallithea-Community zusammenzuarbeiten, um die Hürden für die Arbeit mit und an Kallithea SCM zu senken, sowie mit dem PSF-Infrastrukturteam zusammenzuarbeiten, um sicherzustellen, dass der forge.python.org-Service nahtlos mit der Infrastrukturautomatisierung der PSF integriert wird.

Dieser Ansatz zielt darauf ab, eine Reihe von Schlüsselvorteilen zu bieten:

• uns denjenigen, die zur Wartung dieses Dienstes beitragen, die größtmögliche Produktivität in der zur Verfügung stehenden Zeit zu ermöglichen
• den Freiwilligen, die sich an der Wartung dieses Dienstes beteiligen, eine überzeugende professionelle Entwicklungsmöglichkeit zu bieten
• das Kallithea-Projekt selbst für andere potenzielle Benutzer attraktiver zu machen, indem es die Übernahme, Bereitstellung und Verwaltung so einfach wie möglich gestaltet
• als Ergebnis der oben genannten Vorteile genügend Mitwirkende sowohl in der Upstream-Kallithea-Community als auch innerhalb der CPython-Infrastruktur-Community zu gewinnen, damit der forge.python.org-Service effektiv weiterentwickelt werden kann, um sich ändernden Entwicklererwartungen gerecht zu werden

Einige erste Schritte wurden bereits unternommen, um diese Bedenken hinsichtlich der Wartungstechnik anzugehen:

• Tymoteusz Jankowski arbeitet mit Donald Stufft zusammen, um zu ermitteln, was erforderlich wäre, um Kallithea mit der Salt-basierten Infrastrukturautomatisierung der PSF bereitzustellen.
• Graham Dumpleton und ich haben daran gearbeitet, Demo-Kallithea-Instanzen einfach auf der kostenlosen Stufe des Open-Source-Hosting-Dienstes von Red Hat, OpenShift Online, bereitzustellen. (Siehe die Kommentare zu diesem Beitrag oder den Quickstart-Issue-Tracker für Links zu Grahams Folgearbeiten)

Der nächste wichtige Schritt besteht darin, einen lokalen Entwicklungs-Workflow zu entwickeln, der es Mitwirkenden auf Windows, Mac OS X und Linux ermöglicht, die Kallithea-Tests lokal auszuführen, ohne den Betrieb ihres eigenen Systems zu beeinträchtigen. Der derzeit geplante Ansatz hierfür ist die Konzentration auf Vagrant, ein beliebtes automatisiertes Virtual-Machine-Management-System, das speziell für Entwickler entwickelt wurde, die lokale VMs zu Testzwecken verwenden. Die Vagrant-basierten Entwicklungsrichtlinien für OpenShift Origin bieten ein erweitertes Beispiel für die Art von Workflow, die dieser Ansatz ermöglicht. Es ist auch erwähnenswert, dass Vagrant eine der Optionen für die Arbeit mit einem lokalen Build der Hauptwebsite von python.org ist.

Wenn sich diese Workflow-Vorschläge für Kallithea gut bewähren, könnten sie auch für die Upstream-Projekte, die andere PSF- und CPython-Infrastrukturdienste unterstützen, einschließlich Roundup, BuildBot und der Hauptwebsite python.org, vorgeschlagen werden.

Persönliche Motivation

Seit Juli 2015 arbeite ich bei Red Hat als Designer für Softwareentwicklungs-Workflows und Prozessarchitekt, mit Schwerpunkt auf der Upstream-Entwicklererfahrung in Fedora. Zwei der wichtigsten Elemente dieser Erfahrung werden vielen Webdienstentwicklern vertraut sein: Docker für das lokale Container-Management und Vagrant für das plattformübergreifende lokale Entwicklungs-VM-Management. Die Zeit, die ich für die Anwendung dieser Technologien in mehreren Upstream-Kontexten aufwende, liefert zusätzliche Einblicke in das, was gut funktioniert und was noch verbessert werden muss, um eine gute Softwareentwicklungserfahrung zu bieten, die gut in Fedora integriert ist, aber auch auf anderen Linux-Distributionen, Windows und Mac OS X leicht verfügbar ist.

Insbesondere im Bereich Code-Review-Workflows sind die wichtigsten Tools für das Management von Code-Review-Workflows, die ich in meiner Karriere verwendet habe, Gerrit (für mehrstufige Code-Reviews mit feingranularer Zugriffskontrolle), GitHub und BitBucket (für grundlegende Pull-Request-basierte Workflows) und Rietveld (für optionale Pre-Commit-Reviews von CPython).

Kallithea ist interessant als Basisprojekt zum Aufbau, da es derzeit eine kombinierte Plattform für Repository-Hosting und Code-Review-Management ist, die beiden aber nicht direkt integriert, indem es Online-Merges anbietet. Dies schafft die Möglichkeit, die Vorteile des GitHub/BitBucket-Pull-Request-Modells mit seinem niedrigen Einstiegsniveau mit den Vorteilen von Gerrit für Mentoring und Aufgabenübergabe zu kombinieren, um ein Online-Code-Merging-Modell für Kallithea in Zusammenarbeit mit den Upstream-Kallithea-Entwicklern zu definieren.

Technische Bedenken und Herausforderungen

Die Einführung eines neuen Dienstes in die CPython-Infrastruktur birgt eine Reihe interessanter technischer Bedenken und Herausforderungen. Dieser Abschnitt behandelt einige der wichtigsten.

Pilotziele und Zeitplan

[TODO: Aktualisieren Sie diesen Abschnitt für Bretts überarbeiteten Zeitplan, der darauf abzielt, bis zum 31. Oktober ein CPython-Demo-Repository online zu haben, um ein besseres Verständnis für zukünftige Funktionen zu erhalten, sobald CPython selbst in das neue System migriert, anstatt nur die Support-Repos]

Dieser Vorschlag ist Teil von Brett Cannons aktueller Bewertung von Verbesserungsvorschlägen für verschiedene Aspekte des CPython-Entwicklungs-Workflows. Schlüsseldaten in diesem Zeitplan sind:

• 1. Feb: Entwurf des Vorschlags veröffentlicht (für Kallithea, dieser PEP)
• 8. Apr: Diskussion der endgültigen Vorschläge auf dem Python Language Summit
• 1. Mai: Bretts Entscheidung, welcher Vorschlag akzeptiert wird
• 13. Sep: Python 3.5 veröffentlicht, Einführung neuer Workflows für Python 3.6

Wenn dieser Vorschlag für die Weiterentwicklung ausgewählt wird, wird vorgeschlagen, mit der Einführung des folgenden Pilotprojekts zu beginnen:

• eine Referenzimplementierung, die unter kallithea-pilot.python.org betriebsbereit ist und mindestens das Entwicklerhandbuch und die PEP-Repositories enthält. Dies wird eine „Wegwerf“-Instanz sein, die es Kernentwicklern und anderen Mitwirkenden ermöglicht, frei zu experimentieren, ohne sich um die langfristigen Auswirkungen auf die Repository-Historie zu kümmern.
• Schreibgeschützte Live-Spiegel der Kallithea-gehosteten Repositories auf GitHub und BitBucket. Wie bei der Pilot-Dienst selbst wären dies temporäre Repos, die nach Ablauf der Pilotperiode verworfen werden.
• Klare Dokumentation zur Verwendung dieser Spiegel, um Pull-Anfragen an Kallithea-gehostete Mercurial-Repositories zu erstellen (für den Piloten wird dies wahrscheinlich nicht die Verwendung der nativen Pull-Request-Workflows dieser gehosteten Dienste beinhalten)
• Automatische Verknüpfung von Issue-Referenzen in Code-Review-Kommentaren und Commit-Nachrichten mit den entsprechenden Issues auf bugs.python.org
• Entwurfsaktualisierungen von PEP 1, die den auf Kallithea basierenden Workflow für die Bearbeitung und Einreichung von PEPs erklären

Die folgenden Punkte wären für eine Produktionsmigration erforderlich, aber es scheint keinen offensichtlichen Weg zu geben, eine aktualisierte Implementierung als Teil des Piloten zu testen:

• Anpassung des PEP-Veröffentlichungsprozesses und des Entwicklerhandbuch-Veröffentlichungsprozesses, um auf den verlagerten Mercurial-Repositories zu basieren

Die folgenden Punkte wären Ziele des gesamten Workflow-Verbesserungsprozesses, werden aber als „wünschenswert, aber nicht wesentlich“ für die anfängliche Einführung des neuen Dienstes im September angesehen (wenn dieser Vorschlag ausgewählt wird und die vorgeschlagene Pilotbereitstellung erfolgreich ist):

• Ermöglichung der Verwendung von python-social-auth zur Authentifizierung gegen die von der PSF gehostete Kallithea-Instanz
• Ermöglichung der Verwendung der GitHub- und BitBucket-Pull-Request-Workflows zur Einreichung von Pull-Anfragen an das Haupt-Kallithea-Repository
• Einfaches Auslösen von erzwungenen BuildBot-Läufen basierend auf Kallithea-gehosteten Repositories und Pull-Anfragen (vor der Implementierung von PEP 462 wäre dies zur Verwendung mit Sandbox-Repositories und nicht mit dem Haupt-CPython-Repository vorgesehen)

Zukünftige Auswirkungen auf die CPython-Kernentwicklung

Die Workflow-Anforderungen für das Haupt-CPython-Entwicklungsrepository sind erheblich komplexer als die für die in diesem PEP diskutierten Repositories. Diese Bedenken werden in PEP 462 ausführlicher behandelt.

Angesichts von Guidos Empfehlung, Rietveld durch ein aktiver gewartetes Code-Review-System zu ersetzen, ist mein aktueller Plan, diesen PEP neu zu schreiben, um Kallithea als vorgeschlagene Klebeschicht zu verwenden, wobei verbesserte Kallithea-Pull-Anfragen schließlich die aktuelle Praxis des Hochladens von Patch-Dateien direkt in den Issue-Tracker ersetzen.

Ich habe auch begonnen, mit Pierre Yves-David an einer benutzerdefinierten Mercurial-Erweiterung zu arbeiten, die einige Aspekte des CPython-Kernentwicklungs-Workflows automatisiert.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.