Zusammenfassung

Diese PEP schlägt vor, in die Automatisierung mehrerer mühsamer, zeitaufwändiger Tätigkeiten zu investieren, die derzeit für das Kernentwicklungsteam erforderlich sind, um Änderungen in CPython zu integrieren. Dieser Vorschlag zielt darauf ab, Kernentwicklern eine effektivere Nutzung der ihnen zur Verfügung stehenden Zeit für Beiträge zu CPython zu ermöglichen, was auch zu einer verbesserten Erfahrung für andere Mitwirkende führen sollte, die darauf angewiesen sind, dass das Kernteam ihre Änderungen einarbeitet.

Rücknahme eines PEP

Diese PEP wurde vom Autor zugunsten des auf GitLab basierenden Vorschlags in PEP 507 zurückgezogen.

Wenn jemand anders diese PEP weiter vorantreiben möchte, kontaktieren Sie bitte die Mailingliste core-workflow.

Begründung für Änderungen am Kernentwicklungs-Workflow

Der aktuelle Kernentwicklungs-Workflow zur Einbindung einer neuen Funktion in CPython unter einem POSIX-System funktioniert wie folgt:

1. Wenn Sie eine Änderung anwenden, die von einem anderen Benutzer auf bugs.python.org eingereicht wurde, überprüfen Sie zuerst, ob er die PSF Contributor Licensing Agreement unterzeichnet hat. Wenn nicht, bitten Sie ihn, eine solche zu unterzeichnen, bevor Sie mit dem Zusammenführen der Änderung fortfahren.
2. Wenden Sie die Änderung lokal auf einen aktuellen Checkout des Haupt-CPython-Repositorys an (die Änderung wurde in der Regel zuerst als Patch auf bugs.python.org diskutiert und überprüft, aber dieser Schritt wird derzeit nicht als zwingend für Änderungen betrachtet, die direkt von Kernentwicklern stammen).
3. Führen Sie die Testsuite lokal aus, mindestens make test oder ./python -m test (je nach Systemkonfiguration dauert dies in der Standardkonfiguration einige Minuten, aber erheblich länger, wenn alle optionalen Ressourcen wie externer Netzwerkzugriff aktiviert sind).
4. Führen Sie make patchcheck aus, um alle Whitespace-Probleme zu beheben und als Erinnerung an andere erforderliche Änderungen (wie das Aktualisieren von Misc/ACKS oder das Hinzufügen eines Eintrags zu Misc/NEWS).
5. Committen Sie die Änderung und pushen Sie sie in das Haupt-Repository. Wenn hg anzeigt, dass dies einen neuen Head im Remote-Repository erstellen würde, führen Sie hg pull --rebase (oder ein Äquivalent) aus. Theoretisch sollten Sie die Tests an diesem Punkt erneut ausführen, aber es ist *sehr* verlockend, diesen Schritt zu überspringen.
6. Überwachen Sie nach dem Pushen die stabilen Buildbots auf neue Fehler, die durch Ihre Änderung eingeführt wurden. Insbesondere Entwickler auf POSIX-Systemen brechen oft die Windows-Buildbots und umgekehrt. Weniger häufig brechen Entwickler auf Linux oder Mac OS X andere POSIX-Systeme.

Die unter Windows erforderlichen Schritte sind ähnlich, aber die genauen Befehle sind unterschiedlich.

Anstatt einfacher zu sein, ist der Workflow für einen Bugfix *komplizierter* als für eine neue Funktion! Neue Funktionen haben den Vorteil, dass sie nur auf den default-Zweig angewendet werden, während Bugfixes auch für die Einbeziehung in Wartungszweige berücksichtigt werden müssen.

• Wenn ein Bugfix für Python 2.7 anwendbar ist, wird er auch separat auf den 2.7-Zweig angewendet, der als unabhängiger Head in Mercurial gepflegt wird.
• Wenn ein Bugfix für die aktuelle 3.x-Wartungsversion anwendbar ist, wird er zuerst auf den Wartungszweig angewendet und dann zum Default-Zweig gemerged. Beide Zweige werden gleichzeitig auf hg.python.org gepusht.

Dokumentations-Patches sind einfacher als Funktions-Patches, aber nicht wesentlich – der Hauptvorteil ist, dass nur der erfolgreiche Build der Dokumentation überprüft werden muss, anstatt die Testsuite auszuführen.

Ich schätze, dass es selbst dann, wenn alles reibungslos verläuft, immer noch mindestens 20-30 Minuten dauern würde, einen Bugfix-Patch einzuchecken, der sauber anwendbar ist. Da es möglich sein sollte, mehrere dieser Aufgaben zu automatisieren, glaube ich nicht, dass unsere aktuellen Praktiken knappe Kernentwicklungsressourcen effektiv nutzen.

Es gibt viele, viele Frustrationen mit diesem aktuellen Workflow, die direkt zu einigen unerwünschten Entwicklungspraktiken führen.

• Ein Großteil dieses Overhead entsteht pro angewendetem Patch. Dies fördert große Commits anstelle von kleinen, isolierten Änderungen. Die Zeit, die zum Einchecken einer 500-Zeilen-Funktion benötigt wird, ist im Wesentlichen die gleiche wie die für das Einchecken eines 1-Zeilen-Bugfixes – die zusätzliche Zeit für die größere Änderung erscheint in einer vorherigen Überprüfung und nicht als Teil des Commit-Prozesses.
• Der zusätzliche Overhead bei der Bearbeitung von Bugfixes schafft einen zusätzlichen Anreiz, stattdessen an neuen Funktionen zu arbeiten, und neue Funktionen sind von Natur aus interessanter – sie brauchen keine Workflow-Schwierigkeiten, die ihnen einen Schub geben!
• Eine vorherige Überprüfung auf bugs.python.org zu erhalten, ist *zusätzliche* Arbeit, was einen Anreiz schafft, Änderungen direkt einzuchecken, und die Abhängigkeit von der Nachüberprüfung auf der python-checkins-Mailingliste erhöht.
• Patches im Tracker, die vollständig, korrekt und zum Mergen bereit sind, können immer noch lange Zeit liegen bleiben, bis ein Kernentwickler die Zeit hat, sie einzubinden.
• Das Risiko von Push-Races (insbesondere beim Pushen eines gemergten Bugfixes) verleitet dazu, vollständige lokale Testläufe zu überspringen (insbesondere nachdem bereits einmal eine Push-Race aufgetreten ist), was die Wahrscheinlichkeit erhöht, die Buildbots zu brechen.
• Die Buildbots sind manchmal längere Zeit rot, was Fehler in lokale Testläufe einführt und auch bedeutet, dass sie manchmal keine zuverlässige Anzeige dafür sind, ob ein Patch plattformübergreifende Probleme eingeführt hat.
• Post-Konferenz-Entwicklungssprints sind ein Albtraum, da sie in einem Sumpf von Push-Races versinken. Es ist verlockend, Patches bis nach dem Sprint im Tracker zu lassen und dann später aufzuräumen.

Es gibt auch viele, viele Gelegenheiten für Kernentwickler, Fehler zu machen, die andere belästigen, sowohl bei der Verwaltung der Mercurial-Zweige als auch beim Brechen der Buildbots, ohne in der Lage zu sein, sie umgehend zu beheben. Dies macht sowohl das bestehende Kernentwicklungsteam vorsichtig bei der Vergabe von Commit-Zugriff an neue Entwickler, als auch neue Entwickler vorsichtig, wenn sie ihren erhöhten Zugriff tatsächlich nutzen.

Es gibt auch einige zufällige Ärgernisse (wie die Aktualisierung der NEWS-Datei), die im Rahmen dieses Vorschlags ebenfalls behandelt werden müssen.

Eine der kritischsten Ressourcen eines freiwillig geführten Open-Source-Projekts ist die emotionale Energie seiner Mitwirkenden. Der aktuelle Ansatz zur Einbindung von Änderungen schneidet in dieser Hinsicht für niemanden gut ab.

• Für Kernentwickler ist das Verwalten von Zweigen für Bugfixes heikel und leicht zu falsch zu machen. Konflikte in der NEWS-Datei und Push-Races beim Hochladen von Änderungen tragen zur Reizung bei, wenn die meisten von uns nicht dafür bezahlt werden, Zeit damit zu verbringen (und für diejenigen, die es sind, ist die Mitarbeit an CPython wahrscheinlich nur eine ihrer Verantwortlichkeiten). Die Zeit, die wir tatsächlich mit dem Mergen einer Änderung verbringen, ist Zeit, die wir nicht mit dem Codieren zusätzlicher Änderungen, dem Schreiben oder Aktualisieren von Dokumentationen oder dem Überprüfen von Beiträgen anderer verbringen.
• Rote Buildbots erschweren anderen Entwicklern das Leben (da ein lokaler Testfehler *nicht* auf etwas zurückzuführen sein kann, das dieser Entwickler getan hat), Release-Managern (da sie möglicherweise Hilfe beim Bereinigen von Testfehlern vor einer Veröffentlichung benötigen) und den Entwicklern selbst (da dies erheblichen Druck erzeugt, alle unbeabsichtigt eingeführten Fehler sofort zu beheben und es potenziell schwieriger macht, hg bisect zu verwenden, wenn hg annotate nicht ausreicht, um die Quelle eines neuen Fehlers zu identifizieren).
• Für andere Mitwirkende ist ein Kernentwickler, der Zeit mit dem Mergen von Änderungen verbringt, ein Entwickler, der keine Patches auf dem Issue-Tracker überprüft und diskutiert oder andere bei der effektiven Beitragsleistung unterstützt. Es ist besonders frustrierend für Mitwirkende, die an die Einfachheit gewöhnt sind, dass ein Entwickler einfach auf „Merge“ bei einer Pull-Anfrage klickt, die bereits automatisch im CI-System des Projekts getestet wurde (was ein gängiger Workflow auf Seiten wie GitHub und BitBucket ist), oder wo der Nachprüfungs-Teil des Merge-Prozesses vollständig automatisiert ist (wie bei OpenStack).

Aktuelle Werkzeuge

Die folgenden Werkzeuge werden derzeit zur Verwaltung verschiedener Teile des CPython-Kernentwicklungs-Workflows verwendet.

• Mercurial (hg.python.org) für die Versionskontrolle
• Roundup (bugs.python.org) für die Fehlerverfolgung
• Rietveld (ebenfalls auf bugs.python.org gehostet) für die Code-Überprüfung
• Buildbot (buildbot.python.org) für automatisiertes Testen

Dieser Vorschlag schlägt vor, die Nutzung von Rietveld für die Code-Überprüfung durch den funktionsreicheren, auf Kallithea basierenden forge.python.org-Dienst zu ersetzen, wie in PEP 474 vorgeschlagen. Guido hat angedeutet, dass die ursprüngliche Rietveld-Implementierung hauptsächlich als öffentliche Demonstrationsanwendung für Google App Engine gedacht war, und der Wechsel zu Kallithea wird einige Probleme bei der Identifizierung der beabsichtigten Zielzweige beheben, die bei der Arbeit mit Patch-Dateien auf Roundup und den zugehörigen Überprüfungen in der integrierten Rietveld-Instanz auftreten.

Es schlägt auch die Hinzufügung neuer Werkzeuge zur Automatisierung weiterer Teile des Workflows sowie eine kritische Überprüfung der verbleibenden Werkzeuge vor, um zu sehen, welche davon für einen Ersatz in Frage kommen.

Vorschlag

Das Wesen dieses Vorschlags ist, dass CPython ein Entwicklungsmodell mit „Kernprüfern“ annehmen soll, ähnlich dem, das vom OpenStack-Projekt verwendet wird.

Die Workflow-Probleme, die das CPython-Kernentwicklungsteam erlebt, sind nicht einzigartig. Das OpenStack-Infrastrukturteam hat einen gut gestalteten automatisierten Workflow entwickelt, der sicherstellt,

• dass nach der Überprüfung eines Patches nur noch Entwicklerbeteiligung erforderlich ist, wenn die automatisierten Tests vor dem Mergen fehlschlagen.
• dass Patches niemals ohne Test im Verhältnis zum aktuellen Stand des Zweiges gemerged werden.
• dass der Hauptentwicklungszweig immer grün bleibt. Patches, die die automatisierten Tests nicht bestehen, werden nicht gemerged.

Wenn ein Kernentwickler einen Patch vor dem Mergen anpassen möchte, lädt er ihn aus dem Überprüfungstool herunter, modifiziert ihn und lädt ihn *wieder in das Überprüfungstool hoch*, anstatt ihn direkt in das Quellcode-Repository zu pushen.

Der Kern dieses Workflows wird mit einem Werkzeug namens Zuul implementiert, einem speziell für das OpenStack-Projekt entwickelten Python-Webdienst, der jedoch bewusst mit einem Plugin-basierten Trigger- und Aktionssystem entwickelt wurde, um die Anpassung an alternative Code-Überprüfungssysteme, Issue-Tracker und CI-Systeme zu erleichtern. James Blair vom OpenStack-Infrastrukturteam bot eine exzellente Übersicht über Zuul auf linux.conf.au 2014.

Während Zuul mehrere Workflows für OpenStack handhabt, ist der spezifische, der für diese PEP von Interesse ist, der „Merge Gating“-Workflow.

Für diesen Workflow wird Zuul so konfiguriert, dass er das Gerrit-Code-Review-System auf Patches überwacht, die als „Approved“ markiert wurden. Sobald es einen solchen Patch sieht, nimmt Zuul ihn auf und fügt ihn in eine Warteschlange von „Kandidaten-Merges“ ein. Anschließend erstellt es eine Pipeline von Testläufen, die parallel in Jenkins ausgeführt werden (um mehr als 24 Commits pro Tag zu ermöglichen, wenn ein vollständiger Testlauf fast eine Stunde dauert), und die gemerged werden, wenn sie erfolgreich sind (und wenn alle Kandidaten-Merges vor ihnen in der Warteschlange erfolgreich sind). Wenn ein Patch die Tests nicht besteht, nimmt Zuul ihn aus der Warteschlange, bricht alle nachfolgenden Testläufe für diesen Patch ab und baut die Warteschlange ohne den fehlerhaften Patch neu auf.

Wenn ein Entwickler einen Test betrachtet, der beim Mergen fehlgeschlagen ist, und feststellt, dass dies auf einen intermittierenden Fehler zurückzuführen war, kann er den Patch zur erneuten Überprüfung einreichen.

Um diesen Prozess an CPython anzupassen, sollte es möglich sein, Zuul die Kallithea auf genehmigte Pull-Anfragen überwachen zu lassen (was eine Funktionserweiterung in Kallithea erfordern könnte), sie an Buildbot zum Testen auf den stabilen Buildbots zu übergeben und dann die Änderungen entsprechend in Mercurial zu mergen. Diese Idee birgt einige technische Herausforderungen, die ihren eigenen Abschnitt unten haben.

Für CPython glaube ich nicht, dass wir die Fähigkeit von Zuul zur parallelen Ausführung von Tests nutzen müssen (zumindest nicht in der Anfangsphase – wenn wir an einen Punkt gelangen, an dem die serielle Testung von Patches durch das Merge-Gating-System unser Hauptengpass ist, anstatt die Leute zu haben, die wir brauchen, um Patches zu überprüfen und zu genehmigen, dann wird das ein sehr guter Tag sein).

Die Merge-Queue selbst ist jedoch ein sehr mächtiges Konzept, das mehrere der in der Begründung beschriebenen Probleme direkt angehen sollte.

Zurückgestellte Vorschläge

Das OpenStack-Team nutzt Zuul auch zur Koordination verschiedener anderer Aktivitäten.

• Ausführung von vorläufigen „Check“-Tests gegen Patches, die in Gerrit eingereicht wurden.
• Erstellung aktualisierter Release-Artefakte und erneutes Veröffentlichen der Dokumentation bei gemergten Änderungen.
• Die Funktion Elastic recheck, die ElasticSearch in Verbindung mit einem Spamfilter verwendet, um Testausgaben zu überwachen und den spezifischen intermittierenden Fehler vorzuschlagen, der zum Fehlschlagen eines Tests geführt haben könnte, anstatt dass Benutzer Protokolle manuell durchsuchen müssen.

Obwohl dies Möglichkeiten sind, die es wert sind, in Zukunft erforscht zu werden (und einer der möglichen Vorteile, die ich darin sehe, eine engere Koordination mit dem OpenStack-Infrastrukturteam anzustreben), sehe ich sie nicht als die gleiche Art von grundlegender Workflow-Verbesserung wie Merge Gating.

Wenn wir jedoch feststellen, dass wir zu viele Probleme mit intermittierenden Testfehlern im Gate haben, muss die Einführung der Funktion „Elastic recheck“ möglicherweise als Teil der anfänglichen Bereitstellung in Betracht gezogen werden.

Vorgeschlagene Varianten

Terry Reedy hat vorgeschlagen, einen anfänglichen Filter durchzuführen, der speziell nach genehmigten reinen Dokumentations-Patches sucht (~700 der über 4000 offenen CPython-Probleme sind reine Dokumentationsaktualisierungen). Dieser Ansatz würde mehrere Probleme im Zusammenhang mit instabilen Tests und plattformübergreifenden Tests vermeiden und es gleichzeitig ermöglichen, die restlichen Automatisierungsabläufe auszuarbeiten (z. B. wie ein Patch in die Merge-Queue geschoben wird).

Der Hauptnachteil dieses Ansatzes ist, dass Zuul keine vollständige Kontrolle über den Merge-Prozess hat, wie es normalerweise erwartet wird. Daher wäre zusätzliche Koordination erforderlich.

Es könnte sich lohnen, diesen Ansatz als Fallback-Option beizubehalten, falls die anfängliche Bereitstellung mehr Probleme mit der Testzuverlässigkeit aufweist als erwartet.

Es wäre auch möglich, die Merge-Gating-Kriterien so anzupassen, dass die Testsuite nicht ausgeführt wird, wenn erkannt wird, dass der Patch keine Dateien außerhalb des „Docs“-Baums geändert hat, und stattdessen nur prüft, ob die Dokumentation fehlerfrei erstellt wird.

Als weitere Alternative könnte es sinnvoll sein, einige Teile der Dokumentation (wie das Tutorial und die HOWTO-Leitfäden) aus dem Haupt-Quellcode-Repository zu entfernen und sie mit dem einfacheren Pull-Request-basierten Modell zu verwalten, das in PEP 474 beschrieben ist.

Wahrgenommene Vorteile

Die Vorteile dieses Vorschlags kommen dem Kernentwicklungsteam am direktesten zugute. Erstens bedeutet dies, dass, sobald wir einen Patch im aktualisierten Code-Review-System als „Approved“ markieren, *wir normalerweise fertig sind*. Die zusätzlichen 20-30 Minuten (oder mehr) des eigentlichen Anwendens des Patches, des Ausführens der Tests und des Mergens in Mercurial würden alle von Zuul orchestriert. Push-Races wären ebenfalls Geschichte – wenn viele Kernentwickler Patches auf einem Sprint genehmigen, vertieft sich die Warteschlange einfach in Zuul, anstatt dass Entwickler frustriert versuchen, Änderungen zu mergen und scheitern. Testfehler würden immer noch auftreten, aber sie würden dazu führen, dass der betroffene Patch aus der Merge-Warteschlange entfernt wird, anstatt den Code im Haupt-Repository zu brechen.

Da der Großteil des Zeitaufwands in den Überprüfungsprozess verlagert wird, fördert dies auch die „Entwicklung für Überprüfbarkeit“ – kleinere, leichter zu überprüfende Patches, da der Overhead der mehrfachen Ausführung der Tests von Zuul und nicht von den Kernentwicklern übernommen wird.

Die Entfernung dieses Zeitfressers aus dem Kernentwicklungsteam sollte jedoch auch die Erfahrung der CPython-Entwicklung für andere Mitwirkende verbessern, da sie mehrere Gelegenheiten eliminiert, bei denen Patches „auf dem Boden liegen bleiben“, und die Zeit erhöht, die Kernentwickler wahrscheinlich für die Überprüfung von Patches zur Verfügung haben.

Ein weiteres Beispiel für Vorteile für andere Mitwirkende ist, dass während eines Sprints, der hauptsächlich auf neue Mitwirkende abzielt und nur einen einzigen Kernentwickler anwesend hat (wie die Sprints bei PyCon AU in den letzten Jahren), die Merge-Queue es diesem Entwickler ermöglicht, sich mehr auf die Überprüfung von Patches und die Unterstützung anderer Mitwirkender auf dem Sprint zu konzentrieren, da die Annahme eines Patches zur Aufnahme jetzt ein einziger Klick in der Kallithea-UI wäre, anstatt des relativ zeitaufwändigen Prozesses, der er derzeit ist. Selbst wenn mehrere Kernentwickler anwesend sind, ist es besser, ihnen zu ermöglichen, ihre Zeit und Mühe auf die Interaktion mit den anderen Sprintteilnehmern zu verwenden, anstatt auf Dinge, die so mechanisch sind, dass ein Computer sie handhaben kann (und sollte).

Da die meisten Möglichkeiten, beim Einchecken einer Änderung Fehler zu machen, automatisiert entfallen, gibt es auch erheblich weniger Neues zu lernen, wenn ein Mitwirkender als Kernentwickler nominiert wird. Dies sollte einen doppelten Vorteil haben, sowohl indem es den bestehenden Kernentwicklern erleichtert, diese zusätzliche Verantwortung zu übertragen, als auch indem es neuen Mitwirkenden erleichtert, diese wahrzunehmen.

Schließlich erleichtert ein stabilerer Default-Branch in CPython anderen Python-Projekten die Durchführung kontinuierlicher Integration direkt gegen das Haupt-Repository, anstatt darauf warten zu müssen, bis wir uns in der Release-Candidate-Phase einer neuen Veröffentlichung befinden. Derzeit ist die Einrichtung eines solchen Systems nicht besonders attraktiv, da es einen zusätzlichen Mechanismus erfordern würde, um darauf zu warten, bis die eigene Buildbot-Flotte von CPython anzeigt, dass der Build in einem nutzbaren Zustand ist. Mit dem vorgeschlagenen Merge-Gating-System bleibt der Trunk immer nutzbar.

Technische Herausforderungen

Die Anpassung von Zuul von der OpenStack-Infrastruktur an die CPython-Infrastruktur wird zumindest die Entwicklung zusätzlicher Zuul-Trigger- und Aktions-Plugins erfordern und kann zusätzliche Entwicklung in einigen unserer bestehenden Werkzeuge erfordern.

Soziale Herausforderungen

Die primäre soziale Herausforderung besteht darin, das Kernentwicklungsteam dazu zu bringen, seine Praktiken zu ändern. Die mühsamen, aber notwendigen Schritte, die durch den Vorschlag automatisiert werden, sollten jedoch einen starken Anreiz für die bestehenden Entwickler schaffen, dem Vorschlag zuzustimmen.

Ich glaube, dass drei spezifische Funktionen erforderlich sein könnten, um bestehenden Entwicklern zu versichern, dass es keine Nachteile bei der Automatisierung dieses Workflows gibt.

• Es muss nur die Zustimmung eines einzigen Kernentwicklers erforderlich sein, um einen Patch zu integrieren. Dies könnte in Zukunft überarbeitet werden, aber wir sollten den Status quo für die anfängliche Einführung beibehalten.
• Es muss ausdrücklich angegeben werden, dass Kernentwickler ihre eigenen Patches genehmigen dürfen, außer während der Release-Candidate-Phase einer Veröffentlichung. Dies könnte in Zukunft überarbeitet werden, aber wir sollten den Status quo für die anfängliche Einführung beibehalten.
• Es muss sichergestellt werden, dass zumindest Release-Manager über eine „Jetzt mergen“-Funktion verfügen, die es ihnen ermöglicht, einen bestimmten Patch an die Spitze der Merge-Queue zu zwingen. Die Verwendung eines separaten Klons für die Release-Vorbereitung kann dafür ausreichen. Langfristig könnte automatisiertes Merge-Gating auch mehr automatisierte Vorbereitung von Release-Artefakten ermöglichen.

Praktische Herausforderungen

Die PSF betreibt ihre eigene direkt und indirekt gesponserte Workflow-Infrastruktur hauptsächlich aufgrund früherer Erfahrungen mit unannehmbar schlechter Leistung und mangelnder Flexibilität von kostenlos bereitgestellter Infrastruktur für die allgemeine Öffentlichkeit. Die CPython-Entwicklung wurde ursprünglich auf SourceForge gehostet, wobei die Quellcodeverwaltung zu Self-Hosting wechselte, als SF sowohl langsam war, Subversion-Unterstützung anzubieten, als auch unter CVS-Leistungsproblemen litt (siehe PEP 347), während die Fehlerverfolgung später zum Open-Source-Roundup-Issue-Tracker auf dediziertem gesponsertem Hosting (von Upfront Systems) wechselte, aufgrund einer Kombination aus SF-Leistungsproblemen und allgemeinen Benutzerfreundlichkeitsproblemen mit dem SF-Tracker zu dieser Zeit (das Ergebnis und der Prozess für die Auswahl eines neuen Trackers wurden im python.org Wiki und nicht in einer PEP festgehalten).

Dementsprechend werden Vorschläge, die uns auf „SourceForge-Benutzerfreundlichkeit und Zuverlässigkeitsprobleme, Runde zwei“ vorbereiten, auf erheblichen Widerstand von mindestens einigen Mitgliedern des CPython-Kernentwicklungsteams stoßen (einschließlich des Autors dieser PEP). Dieser Vorschlag respektiert diese Geschichte, indem er nur Werkzeuge empfiehlt, die für Self-Hosting als gesponserte oder PSF-finanzierte Infrastruktur verfügbar sind und darüber hinaus Open-Source-Python-Projekte sind, die an die Bedürfnisse des CPython-Kernentwicklungsteams angepasst werden können.

Damit dieser Vorschlag (falls er angenommen wird) erfolgreich ist, müssen wir jedoch verstehen, wie wir die erforderliche Konfiguration, Anpassung, Integration und Bereitstellung durchführen werden.

Der letzte Versuch, ein neues Element zur CPython-Support-Infrastruktur (speed.python.org) hinzuzufügen, ist leider aufgrund mangelnder Zeit der beteiligten Kernentwickler und PSF-Vorstandsmitglieder gescheitert, sowie aufgrund der Schwierigkeiten, jemand anderen schnell einzuarbeiten, um die Aktivität zu leiten (die von HP für dieses Projekt gespendete Hardware wird derzeit stattdessen zur Unterstützung von PyPy verwendet, aber die Situation unterstreicht einige der Herausforderungen, sich auf Freiwilligenarbeit zu verlassen, wenn diese mit vielen anderen höher priorisierten Forderungen an ihre Zeit konfrontiert sind, um Projekte zum Abschluss zu bringen).

Selbst letztendlich erfolgreiche frühere Projekte, wie die Migration der Quellcodeverwaltung von CVS zu Subversion und von Subversion zu Mercurial, die Migration des Issue-Trackers von SourceForge zu Roundup, die Integration der Code-Reviews zwischen Roundup und Rietveld sowie die Einführung der Buildbot Continuous Integration Flotte, haben einen langen Zeitraum in Anspruch genommen, da Freiwillige sich durch die vielen technischen und sozialen Herausforderungen arbeiteten.

Glücklicherweise, da mehrere Aspekte dieses Vorschlags und PEP 474 mit verschiedenen Workflow-Verbesserungen übereinstimmen, die für Red Hats Beaker Open-Source-Hardware-Integrations-Testsyste m und andere arbeitsbezogene Projekte in Betracht gezogen werden, habe ich Vorkehrungen getroffen, um etwa 1 Tag pro Woche für die Arbeit an CPython-Infrastrukturprojekten aufwenden zu können.

Zusammen mit Rackspaces bestehenden Beiträgen zur Wartung der pypi.python.org-Infrastruktur glaube ich persönlich, dass diese Vereinbarung eine allgemeinere Anerkennung unter den CPython-Neuverteilern und Hauptnutzern widerspiegelt, um die Upstream-Infrastruktur durch direkte Beiträge von Entwicklerzeit zu unterstützen, anstatt von freiwilligen Mitwirkenden zu erwarten, dass sie diese Infrastruktur vollständig in ihrer Freizeit warten oder sie indirekt über die PSF finanzieren (mit dem zusätzlichen Verwaltungsaufwand, der damit verbunden wäre). Ich betrachte dies als einen positiven Trend, den ich weiterhin nach besten Kräften fördern werde.

Offene Fragen

So ziemlich alles in der PEP. Wollen wir Merge-Gating und Zuul einführen? Wie wollen wir die verschiedenen technischen Herausforderungen angehen? Sind die Kallithea- und Zuul-Entwicklergemeinschaften offen für die Art von Zusammenarbeit, die für den Erfolg dieses Unterfangens erforderlich wäre?

Obwohl ich Vorkehrungen getroffen habe, einige meiner eigenen Arbeitszeit dafür aufzuwenden, sollten wir die OpenStack Foundation um zusätzliche Unterstützung bitten, da wir eine Schlüsselabhängigkeit von OpenStack selbst sind, Zuul eine Schöpfung des OpenStack-Infrastrukturteams ist und die verfügbaren Entwicklungsressourcen für OpenStack derzeit die für CPython bei weitem übersteigen?

Sind andere interessierte Personen, die für Python-Neuverteiler und Hauptnutzer arbeiten, ebenfalls in der Lage, ihren Vorgesetzten einen geschäftlichen Fall für die Investition von Entwicklerzeit zur Unterstützung dieses Vorhabens zu machen?

Nächste Schritte

Wenn dies verfolgt wird, wird es ein Folgeprojekt zum Kallithea-basierten forge.python.org-Vorschlag in PEP 474 sein. Beachten Sie diese PEP für weitere Details zum laufenden Diskussions-, Überprüfungs- und Proof-of-Concept-Pilotprozess.

Danksagungen

Vielen Dank an Jesse Noller, Alex Gaynor und James Blair für wertvolles Feedback zu einem vorläufigen Entwurf dieses Vorschlags und an James und Monty Taylor für zusätzliches technisches Feedback nach der Veröffentlichung des ersten Entwurfs.

Vielen Dank an Bradley Kuhn, Mads Kiellerich und andere Kallithea-Entwickler für die Diskussionen rund um PEP 474, die zu einer signifikanten Überarbeitung dieses Vorschlags führten, der auf der Verwendung von Kallithea für die Überprüfungskomponente anstelle der bestehenden Rietveld-Installation basiert.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.