Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 512 – Migration von hg.python.org zu GitHub

Autor:
Brett Cannon <brett at python.org>
Discussions-To:
Core-Workflow-Liste
Status:
Final
Typ:
Prozess
Erstellt:
17-Jan-2015
Post-History:
17-Jan-2016, 19-Jan-2016, 23-Jan-2016
Inhaltsverzeichnis

Hinweis

Die Entwicklung von CPython wurde am 10.02.2017 zu https://github.com/python/cpython verlagert.

Zusammenfassung

Dieses PEP umreißt die Schritte, die für die Migration des Entwicklungsprozesses von Python von Mercurial [3], gehostet auf hg.python.org [1], zu Git [4] auf GitHub [2] erforderlich sind. Die Erfüllung der Mindestziele dieses PEPs sollte den Entwicklungsprozess von Python so produktiv wie derzeit ermöglichen, und die Erfüllung seiner erweiterten Ziele sollte den Entwicklungsprozess gegenüber dem Status quo verbessern.

Begründung

Im Jahr 2014 wurde deutlich, dass der benutzerdefinierte Entwicklungsprozess von Python zu einem Hindernis wurde. Als Beispiel, damit ein externer Beitragender eine Korrektur für einen Fehler einreichen konnte, der schließlich committet wurde, waren die grundlegenden Schritte:

  1. Öffnen eines Issues für den Fehler auf bugs.python.org [5].
  2. Auschecken des CPython-Quellcodes von hg.python.org [1].
  3. Die Korrektur vornehmen.
  4. Einen Patch hochladen.
  5. Ein Kernentwickler überprüft den Patch mit unserer Fork des Rietveld-Code-Review-Tools [6].
  6. Den Patch herunterladen, um sicherzustellen, dass er sich noch sauber anwenden lässt.
  7. Die Testsuite manuell ausführen.
  8. Die Dateien NEWS, ACKS und das Dokument „What’s New“ nach Bedarf aktualisieren
  9. Änderungen ziehen, um ein Merge-Rennen zu vermeiden.
  10. Die Änderung manuell committen.
  11. Wenn die Änderung für einen Bugfix-Release war, in den in Entwicklung befindlichen Branch mergen.
  12. Die Testsuite manuell erneut ausführen.
  13. Den Merge committen.
  14. Die Änderungen pushen.

Dies ist ein sehr schwerfälliger, manueller Prozess für Kernentwickler. Selbst im einfachen Fall konnte man nur den Code-Review-Schritt überspringen, da man immer noch die Dokumentation erstellen musste. Dies führte dazu, dass Patches auf dem Issue-Tracker liegen blieben, da die Kernentwickler den Rückstand nicht schnell genug bearbeiten konnten, um mit den Einreichungen Schritt zu halten. Dies wiederum führte zu einem Nebenproblem, nämlich der Entmutigung externer Beiträge aufgrund von Frustration über mangelnde Aufmerksamkeit, was ein gefährliches Problem für ein Open-Source-Projekt ohne Unternehmensunterstützung darstellt, da es dem Projekt eine lebensfähige Zukunft entgegenwirkt. Während das Hochladen von Patches auf bugs.python.org [5] für einen externen Beitragenden potenziell einfach ist, ist es für einen Kernentwickler der langsamste und mühsamste Prozess.

Daher wurde Ende 2014 die Entscheidung getroffen, dass ein Wechsel zu einem neuen Entwicklungsprozess notwendig ist. Es wurde ein Aufruf zu PEPs für neue Workflows gemacht, was schließlich zu zweien führte: PEP 481 und PEP 507, die GitHub [2] bzw. GitLab [7] vorschlugen.

Das Jahr 2015 wurde immer wieder mit der Arbeit an diesen Vorschlägen und dem Versuch verbracht, die Details dessen, was sie voneinander unterscheidet, auf der Core-Workflow-Mailingliste herauszuarbeiten [8]. PyCon US 2015 zeigte auch, dass die Community etwas frustriert über unseren Prozess war, sowohl wegen des kognitiven Aufwands für neue Beitragende als auch wegen der langen Zeit, die Kernentwickler für die Überprüfung eines Patches benötigten (siehe das Ende von Guido van Rossums Keynote auf der PyCon US 2015 [9] als Beispiel für die Frustration).

Am 1. Januar 2016 wurde von Brett Cannon die Entscheidung getroffen, den Entwicklungsprozess auf GitHub zu verlagern. Die Hauptgründe für die Wahl von GitHub waren [10]:

  • Die Pflege kundenspezifischer Infrastruktur war für Freiwillige eine Belastung (z. B. wird derzeit eine nicht gewartete, kundenspezifische Fork von Rietveld [6] verwendet).
  • Der kundenspezifische Workflow ist für Kernentwickler sehr zeitaufwendig (nicht genügend automatisierte Werkzeuge zur Unterstützung).
  • Der kundenspezifische Workflow ist ein Hindernis für externe Beitragende (wirkt als Einstiegsbarriere aufgrund der Zeit, die für die Einarbeitung in den spezifischen CPython-Entwicklungsprozess benötigt wird).
  • Es gibt kein Merkmal, das GitLab von GitHub unterscheidet, außer dass GitLab Open Source ist.
  • Die Vertrautheit mit GitHub ist unter Kernentwicklern und externen Beitragenden weitaus höher als mit GitLab.
  • Unser BDFL bevorzugt GitHub (der uns als Erster sagen würde, dass seine Meinung keine Rolle spielen sollte, aber die Person, die die Entscheidung trifft, hielt es für wichtig, dass sich der BDFL mit dem Workflow seiner eigenen Programmiersprache wohlfühlt, um seine fortgesetzte Teilnahme zu fördern).

Es gibt sogar bereits ein inoffizielles Logo, das die Migration zu GitHub repräsentiert [22].

Das übergeordnete Ziel dieser Migration ist es, den Entwicklungsprozess so zu verbessern, dass ein Kernentwickler von der Einreichung eines externen Beitrags über alle Schritte bis hin zum Committen dieses Beitrags aus einem Browser auf einem Tablet mit WLAN und *einem* Entwicklungsprozess (dies bedeutet nicht zwangsläufig den Standard-Workflow von GitHub) wechseln kann. Die endgültige Lösung wird es auch externen Beitragenden ermöglichen, beizutragen, auch wenn sie sich gegen die Nutzung von GitHub entscheiden (obwohl keine Garantie für Funktionsparität besteht).

Zu migrierende Repositories

Obwohl hg.python.org [1] viele Repositories hostet, gibt es nur fünf Schlüssel-Repositories, die verschoben werden müssen:

  1. devinabox [12] (erledigt)
  2. benchmarks [11] (übersprungen)
  3. peps [13] (erledigt)
  4. devguide [14] (erledigt)
  5. cpython [15]

Das devinabox-Repository ist nur Code. Die Repositories peps und devguide beinhalten die Generierung von Webseiten. Und das cpython-Repository hat spezielle Anforderungen für die Integration mit bugs.python.org [5].

Migrationsplan

Der Migrationsplan ist in Abschnitte unterteilt, basierend auf dem, was für die Migration der Repositories im Abschnitt Zu migrierende Repositories erforderlich ist. Der Abschluss der in jedem Abschnitt dargelegten Anforderungen sollte die Migration der zugehörigen Repositories ermöglichen. Die Abschnitte sollen in Reihenfolge abgeschlossen werden, nicht unbedingt die Anforderungen innerhalb eines Abschnitts.

Anforderungen für reine Code-Repositories

Der Abschluss der Anforderungen in diesem Abschnitt wird die Migration des devinabox-Repositories nach GitHub ermöglichen.

Erstellen eines ‚Python core‘-Teams

Zur Verwaltung von Berechtigungen wird ein ‚Python core‘-Team als Teil der python-Organisation [16] erstellt. Jedes Repository, das verschoben wird, erhält das ‚Python core‘-Team mit Schreibberechtigungen [17]. Jeder, der zuvor die Rechte zur Verwaltung von SSH-Schlüsseln auf hg.python.org hatte, wird zum Team-Maintainer für das ‚Python core‘-Team.

Definieren von Befehlen zur Überführung eines Mercurial-Repositories nach Git

Da der Umzug zu GitHub auch einen Umzug zu Git [4] beinhaltet, müssen wir entscheiden, welche Werkzeuge und Befehle wir ausführen werden, um ein Mercurial-Repository in Git zu übersetzen. Die speziell für diese Migration entwickelten Werkzeuge werden unter https://github.com/orsenthil/cpython-hg-to-git gehostet.

CLA-Durchsetzung

Ein wichtiger Teil jedes Open-Source-Projekts ist die Sicherstellung, dass sein Quellcode ordnungsgemäß lizenziert werden kann. Dies erfordert, dass alle Beitragenden eine Contributor License Agreement (CLA) [18] unterzeichnet haben. Bisher wurde die Durchsetzung der CLA-Unterzeichnung von beigetragenem Code von Kernentwicklern gehandhabt, indem überprüft wurde, ob jemand ein „*“ neben seinem Benutzernamen auf bugs.python.org [5] hatte. Mit dieser Migration ist geplant, mit automatisierter Überprüfung und Durchsetzung der CLA-Unterzeichnung durch die Beitragenden zu beginnen.

Hinzufügen von GitHub-Benutzernamen-Unterstützung zu bugs.python.org

Um die Nachverfolgung der CLA-Unterzeichnung unter direkter Kontrolle der PSF zu halten, wird die Nachverfolgung, wer die PSF CLA unterzeichnet hat, fortgesetzt, indem diese Tatsache als Teil des Benutzerprofils von bugs.python.org markiert wird. Das bedeutet, dass eine Zuordnung zwischen dem bugs.python.org [5]-Konto einer Person und ihrem GitHub-Konto erforderlich ist, was über ein neues Feld im Benutzerprofil erfolgen wird. Dies impliziert, dass Beitragende sowohl ein GitHub [2]- als auch ein bugs.python.org-Konto benötigen, um die CLA zu unterzeichnen und über GitHub beizutragen.

Eine API wird bereitgestellt, um bugs.python.org abzufragen, ob ein GitHub-Benutzername einer Person entspricht, die die CLA unterzeichnet hat. Eine GET-Anfrage an z.B. http://bugs.python.org/user?@template=clacheck&github_names=brettcannon,notanuser gibt ein JSON-Dictionary mit den Schlüsseln der angeforderten Benutzernamen und einem true-Wert zurück, wenn sie die CLA unterzeichnet haben, false, wenn nicht, und null, wenn kein entsprechender GitHub-Benutzername gefunden wurde.

Ein Bot zur Durchsetzung der CLA-Unterzeichnung

Mit einer Zuordnung zwischen dem GitHub-Konto einer Person und ihrem bugs.python.org [5]-Konto, das die Daten darüber enthält, ob jemand die CLA unterzeichnet hat, kann ein Bot Pull Requests auf GitHub überwachen und kennzeichnen, ob der Beitragende die CLA unterzeichnet hat.

Wenn der Benutzer die CLA unterzeichnet hat, fügt der Bot ein positives Label zum Issue hinzu, um anzuzeigen, dass der Pull Request keine CLA-Probleme hat (z. B. ein grünes Label mit der Aufschrift „CLA signed“). Wenn der Beitragende keine CLA unterzeichnet hat, wird ein negatives Label zum Pull Request hinzugefügt und der Pull Request wird über die GitHub-Status-API blockiert (z. B. ein rotes Label mit der Aufschrift „CLA not signed“). Wenn einem Beitragenden ein bugs.python.org-Konto fehlt, führt dies ebenfalls zu dem negativen Label. Die Verwendung eines Labels für positive und negative Fälle bietet ein Fallback-Signal, falls der Bot ausfällt, und verhindert potenzielle Fehlalarme oder Falschnegativ. Es ermöglicht auch eine einfache Möglichkeit, den Bot erneut auszulösen, indem einfach ein CLA-bezogenes Label entfernt wird (dies steht im Gegensatz zur Verwendung einer GitHub-Statusprüfung [40], die nur bei Code-Änderungen ausgelöst wird).

Da kein bestehender Bot existiert, der unseren Anforderungen entspricht, wird er auf Heroku [39] gehostet und so geschrieben, dass er auf Python 3.5 abzielt, um als Showcase für asynchrone Programmierung zu dienen. Der Code für den Bot wird im Knights Who Say Ni-Projekt gehostet [41].

Altes Repository schreibgeschützt machen

Aktualisierung von .hg/hgrc im nun alten Mercurial-Repository im Abschnitt [hooks] mit

pretxnchangegroup.reject = echo " * This repo has been migrated to github.com/python/peps and does not accept new commits in Mercurial!" 2>&1; exit 1

macht das Repository schreibgeschützt.

Anforderungen für das cpython-Repository

Offensichtlich ist das aktivste und wichtigste Repository, das derzeit auf hg.python.org [1] gehostet wird, das cpython-Repository [15]. Aufgrund seiner Bedeutung und hohen Nutzung erfordert es mehr Werkzeuge, bevor es zu GitHub verschoben wird, im Vergleich zu den anderen in diesem PEP erwähnten Repositories.

Schritte zum Committen eines Pull Requests dokumentieren

Während des Prozesses der Auswahl eines neuen Entwicklungs-Workflows wurde beschlossen, dass eine lineare Historie gewünscht ist. Die Leute bevorzugten eine einzelne Commit, die eine einzelne Änderung repräsentiert, anstatt einer Reihe von nicht zusammenhängenden Commits, die zu einem Merge-Commit führen, der eine einzelne Änderung repräsentiert. Das bedeutet, dass die praktische „Merge“-Schaltfläche in GitHub-Pull-Requests so eingestellt wird, dass sie nur *Squash*-Commits und keine Merge-Commits durchführt.

Ein zweiter Satz empfohlener Befehle wird auch zum Committen eines Beitrags aus einer Patchdatei geschrieben, die auf bugs.python.org [5] hochgeladen wird. Dies wird offensichtlich dazu beitragen, die lineare Historie beizubehalten, muss aber so gestaltet werden, dass die Zuschreibung zum Patch-Autor erfolgt.

Die genaue Abfolge von Befehlen, die als Richtlinien für Kernentwickler gegeben werden, ist eine offene Frage: Git CLI-Befehle zum Committen eines Pull Requests nach cpython.

Pull Requests mit Issues verknüpfen

Historisch gesehen wurden externe Beiträge an ein Issue auf bugs.python.org [5] angehängt, dank der Tatsache, dass alle externen Beiträge als Datei hochgeladen wurden. Bei Änderungen, die von einem Kernentwickler direkt committet wurden, führte die Angabe einer Issue-Nummer in der Commit-Nachricht im Format Issue # am Anfang der Nachricht dazu, dass ein Kommentar zum Issue gepostet wurde, der auf den Commit verweist.

Einen Pull Request mit einem Issue verknüpfen

Eine Zuordnung zwischen einem Pull Request und einem Issue ist erforderlich, um zu verfolgen, wann ein Fix vorgeschlagen wurde. Die Zuordnung muss Many-to-One sein, da mehrere Pull Requests zur Lösung eines einzelnen Issues benötigt werden können (technisch gesehen sollte es eine Many-to-Many-Zuordnung sein, wenn ein einzelner Fix mehrere Issues löst, aber das ist ziemlich selten und Issues können mithilfe des Superseder-Feldes im Issue-Tracker zusammengeführt werden).

Die Zuordnung zwischen einem Pull Request und einem Issue erfolgt durch Erkennung einer Issue-Nummer. Wenn das Issue entweder im Titel oder im Text einer Nachricht eines Pull Requests angegeben ist, wird eine Verbindung auf bugs.python.org [5] hergestellt. Eine sichtbare Benachrichtigung – z. B. ein Label oder eine Nachricht – wird an den Pull Request gesendet, um zu benachrichtigen, dass die Zuordnung erfolgreich war.

Den Issue benachrichtigen, wenn ein Commit gemacht wird

Sobald ein Commit gemacht wurde, sollte das entsprechende Issue aktualisiert werden, um dies widerzuspiegeln. Dies sollte unabhängig davon funktionieren, ob der Commit von einem Pull Request oder einem direkten Commit stammt.

Den Verknüpfungsdienst für die Zuordnung von Commit-IDs zu URLs aktualisieren

Derzeit kann man https://hg.python.org/lookup/ mit einer Revisions-ID aus der Subversion- oder Mercurial-Kopie des cpython-Repos [15] verwenden, um zur URL dieser Revision im Mercurial-Repository weitergeleitet zu werden. Der URL-Rewriter muss aktualisiert werden, um auf das Git-Repository weiterzuleiten und die neuen Revisions-IDs zu unterstützen, die für das Git-Repository erstellt wurden.

Das wahrscheinlichste Design ist, alle Mercurial-Änderungsset-Nummern statisch zu kennen, sobald die Migration stattgefunden hat. Der Lookup-Code wird dann aktualisiert, um Hashes von 7 bis 40 hexadezimalen Ziffern zu akzeptieren. Jeder Hexadezimalwert der Länge 12 oder 40 wird mit den Mercurial-Änderungsset-Nummern verglichen. Wenn die Nummer nicht übereinstimmt oder eine andere Länge zwischen 7 und 40 hat, wird angenommen, dass es sich um einen Git-Hash handelt.

Der Commit-Nummern-Rewriter von bugs.python.org muss ebenfalls aktualisiert werden, um Hashes von bis zu 7 Ziffern zu akzeptieren, da Git auf so kurzen oder längeren Hashes übereinstimmt.

sys._mercurial aussondern

Sobald Python nicht mehr in Mercurial gehalten wird, muss das Attribut sys._mercurial auf ('CPython', '', '') geändert werden. Ein äquivalentes Attribut sys._git wird hinzugefügt, das denselben Anwendungsfall erfüllt.

Das Devguide aktualisieren

Das Devguide muss mit Details zum neuen Workflow aktualisiert werden. Wahrscheinlich wird die Arbeit in einem separaten Branch stattfinden, bis die Migration tatsächlich stattfindet.

PEP 101 aktualisieren

Der Release-Prozess muss bei Bedarf aktualisiert werden.

Optionale, geplante Funktionen

Sobald das cpython-Repository [15] migriert ist, werden alle Repositories nach GitHub [2] verschoben sein und der Entwicklungsprozess sollte auf dem gleichen Stand wie vor der Verschiebung sein. Aber ein wichtiger Grund für diese Migration ist, den Entwicklungsprozess zu verbessern und ihn besser zu machen als je zuvor. Dieser Abschnitt skizziert einige Pläne zur Verbesserung der Dinge.

Es sei darauf hingewiesen, dass die Gesamtplanungsplanung für bugs.python.org [5] – die Pläne unabhängig von dieser Migration beinhaltet – auf einer eigenen Wiki-Seite [23] verfolgt wird.

Verarbeitung von Misc/NEWS

Traditionell war die Datei Misc/NEWS [19] problematisch für Änderungen, die sich über Python-Releases erstreckten. Oft gab es Merge-Konflikte beim Committen einer Änderung zwischen z. B. 3.5 und 3.6 nur in der Datei Misc/NEWS. Dies ist so häufig, dass die Beispielanweisungen im Devguide ausdrücklich erwähnen, wie Konflikte in der Datei Misc/NEWS [21] zu lösen sind. Als Teil unserer Werkzeugmodernisierung wird die Arbeit mit der Datei Misc/NEWS vereinfacht.

Der geplante Ansatz ist die Verwendung einer einzelnen Datei pro News-Eintrag, die den Text für den Eintrag enthält. In diesem Szenario hätte jede Feature-Veröffentlichung ihr eigenes Verzeichnis für News-Einträge und eine separate Datei würde in diesem Verzeichnis erstellt, die entweder nach dem geschlossenen Issue oder einem Zeitstempel benannt wäre (was Kollisionen verhindert). Merges zwischen Branches hätten keine Probleme, da die News-Eintragsdatei eindeutig benannt wäre und sich im Verzeichnis der neuesten Version befände, die den Fix enthielt. Ein Skript würde alle News-Eintragsdateien sammeln, egal in welchem Verzeichnis sie sich befinden, und eine entsprechende News-Datei erstellen (das Release-Verzeichnis kann ignoriert werden, da die bloße Existenz der Datei ausreicht, um darzustellen, dass der Eintrag zum Release gehört). Die Klassifizierung kann entweder durch Schlüsselwörter in der neuen Eintragsdatei selbst erfolgen oder durch die Verwendung von Unterverzeichnissen, die jede News-Eintrags-Klassifizierung in jedem Release-Verzeichnis darstellen (oder die Klassifizierung von News-Einträgen könnte entfallen, da kritische Informationen von den „What’s New“-Dokumenten erfasst werden, die organisiert sind). Der Vorteil dieses Ansatzes ist, dass er die Änderungen mit dem Code beibehält, der tatsächlich geändert wurde. Es verbindet auch die Nachricht damit, Teil des Commits zu sein, der die Änderung eingeführt hat. Für einen über die CLI gemachten Commit könnte ein Skript bereitgestellt werden, um beim Generieren der Datei zu helfen. In einem Bot-gesteuerten Szenario könnte der Merge-Bot eine Möglichkeit haben, einen bestimmten News-Eintrag anzugeben und die Datei als Teil seines abgeflachten Commits zu erstellen (während er höchstwahrscheinlich auch die Verwendung der ersten Zeile der Commit-Nachricht unterstützt, wenn kein spezifischer News-Eintrag angegeben wurde). Wenn ein webbasierter Workflow verwendet wird, könnte eine Statusprüfung verwendet werden, um zu überprüfen, ob eine neue Eintragsdatei im Pull Request vorhanden ist, um als Erinnerung zu dienen, dass die Datei fehlt. Code für diesen Ansatz wurde zuvor für den Mercurial-Workflow unter http://bugs.python.org/issue18967 geschrieben. Es gibt auch Werkzeuge von der Community wie https://pypi.python.org/pypi/towncrier, https://github.com/twisted/newsbuilder und http://docs.openstack.org/developer/reno/.

Diskussionen auf den Python-Core-Dev-Sprints im September 2016 führten zu dieser Entscheidung im Vergleich zu den abgelehnten Ansätzen, die im Abschnitt „Abgelehnte Ideen“ dieses PEPs dargelegt sind. Der Ansatz mit separaten Dateien scheint die richtige Balance zwischen Flexibilität und potenziellen Werkzeugen aus den verschiedenen Optionen zu haben und löst gleichzeitig das motivierende Problem.

Die Arbeit hierfür wird unter https://github.com/python/core-workflow/issues/6 verfolgt.

Verarbeitung von Misc/ACKS

Traditionell wurde die Datei Misc/ACKS [20] manuell verwaltet. Aber dank Git, das einen author-Wert sowie einen committer-Wert pro Commit unterstützt, kann die Urheberschaft eines Commits Teil der Historie des Codes selbst sein.

Daher wird die manuelle Verwaltung von Misc/ACKS optional. Ein Skript wird geschrieben, das alle Autoren- und Committer-Namen sammelt und sie in Misc/ACKS mit allen Namen zusammenführt, die vor der Umstellung auf Git aufgeführt waren. Das Ausführen dieses Skripts wird Teil des Release-Prozesses.

Das Skript sollte auch eine Liste aller Personen generieren, die seit der letzten Ausführung beigetragen haben. Dies ermöglicht eine Liste derjenigen, die zu einem bestimmten Release beigetragen haben, damit sie explizit gedankt werden können.

Die Arbeit hierfür wird unter https://github.com/python/core-workflow/issues/7 verfolgt.

Erstellen von https://git.python.org

So wie hg.python.org [1] derzeit auf das Mercurial-Repository für Python verweist, sollte git.python.org das Äquivalent für das Git-Repository tun.

Backup von Pull Request-Daten

Da GitHub [2] für das Hosting und die Code-Überprüfung verwendet wird, müssen diese beiden Dinge gesichert werden. Im Fall des Code-Hostings ist das Backup implizit, da alle nicht-flachen Git [4]-Klone die vollständige Historie des Repositories enthalten, daher wird es viele Backups des Repositories geben.

Die Code-Review-Historie hat keinen ähnlichen impliziten Backup-Mechanismus wie das Repository selbst. Das bedeutet, dass ein tägliches Backup der Code-Review-Historie durchgeführt werden sollte, damit sie im Falle von Problemen mit GitHub nicht verloren geht. Es hilft auch zu garantieren, dass eine Migration von GitHub zu einem anderen Code-Review-System möglich ist, falls GitHub über Nacht verschwinden sollte.

Bot zur Generierung von Cherry-Pick-Pull-Requests

Da die Entscheidung getroffen wurde, mit Cherry-Picks statt mit Forward-Merges von Branches zu arbeiten, wäre es praktisch, einen Bot zu haben, der Pull-Requests basierend auf Cherry-Picks für alle Pull-Requests generiert, die mehrere Branches betreffen. Das wahrscheinlichste Design ist ein Bot, der zusammengeführte Pull-Requests mit bestimmten Labels überwacht, die angeben, in welche Branches der Pull-Request gecherry-picked werden soll. Der Bot würde dann für jedes Label Cherry-Pick-Pull-Requests generieren und die Labels entfernen, sobald die Pull-Requests erstellt sind (dies ermöglicht eine einfache Erkennung, wenn das automatische Cherry-Picking fehlschlägt).

Die Arbeit hierfür wird unter https://github.com/python/core-workflow/issues/8 verfolgt.

Pull Request Commit Queue

Dies würde akzeptierte Pull-Requests linear anwenden und überprüfen, ob die Commits sich nicht gegenseitig gestört haben, indem die Testsuite ausgeführt und Commits zurückgenommen werden, wenn der Testlauf fehlschlägt. Um die Geschwindigkeit des Testens zu beschleunigen, können alle seit dem letzten Testlauf committeten Patches unter einem einzigen Testlauf angewendet werden, da die optimistische Annahme ist, dass die Patches zusammenarbeiten werden. Ein Mechanismus zur erneuten Ausführung der Tests im Falle von Test-Flakiness wird erforderlich sein, sei es durch Entfernen eines „Test fehlgeschlagen“-Labels, einer Weboberfläche für Kernentwickler zur Auslösung eines weiteren Testereignisses usw.

Inspiration oder Grundlage für den Bot kann von bereits existierenden Bots wie Homu [31] oder Zuul [32] genommen werden.

Der Name, der diesem Bot gegeben wird, um ihm Befehle zu geben, ist eine offene Frage: Namen für die Bots.

Ein CI-Dienst

Es gibt verschiedene CI-Dienste, die kostenlosen Support für Open-Source-Projekte auf GitHub [2] bieten. Nach dem Experimentieren mit einigen CI-Diensten wurde die Entscheidung getroffen, sich für Travis [33] zu entscheiden.

Der aktuelle CI-Dienst für Python ist Pypatcher [38]. Es kann eine Anfrage in IRC gestellt werden, um einen Patch von bugs.python.org [5] zu testen. Die Ergebnisse können unter https://ci.centos.org/job/cPython-build-patch/ eingesehen werden.

Die Arbeit hierfür wird unter https://github.com/python/core-workflow/issues/1 verfolgt.

Test-Coverage-Bericht

Das Erhalten eines aktuellen Test-Coverage-Berichts für die Standardbibliothek von Python wäre äußerst vorteilhaft, da die Erstellung eines solchen Berichts ziemlich lange dauern kann.

Es gibt einige bereits existierende Dienste, die kostenlose Testabdeckung für Open-Source-Projekte bieten. Letztendlich wurde Codecov [37] als beste Option gewählt.

Die Arbeit hierfür wird unter https://github.com/python/core-workflow/issues/2 verfolgt.

Benachrichtigung von Issues über Pull Request-Kommentare

Der aktuelle Entwicklungsprozess beinhaltet nicht das Benachrichtigen eines Issues auf bugs.python.org [5], wenn ein Review-Kommentar auf Rietveld [6] hinterlassen wird. Es wäre gut, dies zu beheben, damit Leute sich nur für Kommentare auf bugs.python.org und nicht auf GitHub [2] anmelden können und trotzdem wissen, wann etwas auf GitHub in Bezug auf Review-Kommentare zu relevanten Pull-Requests passiert. Derzeit ist geplant, einen Kommentar auf bugs.python.org zu dem relevanten Issue zu posten, wenn mindestens ein Review-Kommentar über einen bestimmten Zeitraum (z. B. 15 oder 30 Minuten) gemacht wurde, obwohl mit der aktuellen Unterstützung von GitHub für Reviews der Zeitaspekt möglicherweise nicht mehr notwendig ist. Dies reduziert das E-Mail-Volumen für diejenigen, die sowohl GitHub- als auch bugs.python.org-E-Mail-Benachrichtigungen erhalten, und stellt gleichzeitig sicher, dass diejenigen, die nur bugs.python.org verfolgen, wissen, wann es möglicherweise einen zu bearbeitenden Review-Kommentar gibt.

Ermöglichen, dass bugs.python.org GitHub als Login-Anbieter nutzt

Derzeit erlaubt bugs.python.org [5] den Leuten, sich mit Google-, Launchpad- oder OpenID-Anmeldedaten anzumelden. Es wäre gut, dies um GitHub-Anmeldedaten zu erweitern.

Webhooks zur Neuerstellung von Webinhalten

Die Inhalte auf https://docs.pythonlang.de/, https://docs.pythonlang.de/devguide und https://pythonlang.de/dev/peps/ werden alle aus Dateien abgeleitet, die in einem der Repositories aufbewahrt werden, die im Rahmen dieser Migration verschoben werden sollen. Daher wäre es wünschenswert, geeignete Webhooks einzurichten, um die Neuerstellung der entsprechenden Webinhalte auszulösen, wenn sich die zugrunde liegenden Dateien ändern, anstatt auf z. B. einen Cronjob warten zu müssen.

Dies kann teilweise gelöst werden, wenn die Dokumentation ein Sphinx-Projekt ist, da die Seite dann einen inoffiziellen Spiegel auf Read the Docs haben kann, z. B. http://cpython-devguide.readthedocs.io/.

Die Arbeit hierfür wird unter https://github.com/python/core-workflow/issues/9 verfolgt.

Webinhalte zurück zu den Dateien verknüpfen, aus denen sie generiert wurden

Es wäre hilfreich für Personen, die Probleme mit der aus einer Datei generierten Dokumentation feststellen, wenn jede Seite einen Link hätte, der zurück zu der Datei auf GitHub [2] verweist, die den Inhalt der Seite speichert. Dies würde schnelle Pull-Requests zur Behebung einfacher Dinge wie Rechtschreibfehler ermöglichen.

Die Arbeit hierfür wird unter http://bugs.python.org/issue28929 verfolgt.

Aufteilung von Teilen der Dokumentation in eigene Repositories

Während sich bestimmte Teile der Dokumentation auf https://docs.pythonlang.de mit dem Code ändern, sind andere Teile ziemlich statisch und nicht eng an den CPython-Code selbst gebunden. Die folgenden Abschnitte der Dokumentation fallen in diese Kategorie der langsam wechselnden, lose gekoppelten Inhalte:

Diese Teile der Dokumentation könnten in eigene Repositories ausgelagert werden, um deren Wartung zu vereinfachen und die Anzahl der Personen mit Commit-Rechten zu erweitern, um die Wartung zu erleichtern.

Es wurde auch vorgeschlagen, die Dokumente What’s New auszugliedern. Dies würde erfordern, dass entschieden wird, ob ein Workflow entwickelt werden kann, bei dem es schwierig wäre, das Vergessen der Aktualisierung von „What’s New“ zu vermeiden (möglicherweise durch ein Label, das PRs hinzugefügt wird, wie z. B. „What’s New erforderlich“).

Backup von Git-Repositories

Obwohl nicht notwendig, wäre es gut, offizielle Backups der verschiedenen Git-Repositories zum Katastrophenschutz zu haben. Das PSF-Infrastrukturkomitee wird entscheiden müssen, ob dies lohnenswert oder unnötig ist.

Potenzielle neue Kernentwickler identifizieren

Das Python-Entwicklungsteam hat langjährige Richtlinien für die Auswahl neuer Kernentwickler. Der Kern der Richtlinien ist, dass eine Person mehrere Patches beigesteuert haben muss, die akzeptiert wurden und von hoher Qualität und Größe sind, um ein Verständnis des Python-Entwicklungsprozesses zu demonstrieren. Ein Bot könnte geschrieben werden, der die Akzeptanzraten von Patches verfolgt und einen Bericht generiert, um Mitwirkende zu identifizieren, die für die Aufnahme als Kernentwickler in Betracht gezogen werden sollten. Diese Arbeit erfordert nicht einmal unbedingt eine GitHub-Integration, solange das Committer-Feld in allen Git-Commits korrekt ausgefüllt ist.

Die Arbeit wird verfolgt unter https://github.com/python/core-workflow/issues/10.

Status

Anforderungen für die Migration des Repositories devinabox [12]

Repositories, deren Build-Schritte aktualisiert werden müssen

cpython repo [15]

Erforderlich

Optionale Funktionen

Offene Fragen

Für dieses PEP sind offene Probleme solche, bei denen eine Entscheidung getroffen werden muss, wie ein Problem angegangen oder gelöst werden soll. Offene Probleme beinhalten keine Koordinationsprobleme wie z. B. wer einen bestimmten Code schreiben wird.

Das Schicksal von hg.python.org

Da die Code-Repositories zu Git [4] migriert werden, besteht kein technischer Bedarf mehr, hg.python.org [1] weiter zu betreiben. Allerdings möchten einige in der Community, dass es als Mercurial- [3] Spiegel der Git-Repositories weiterläuft. Andere haben gesagt, dass sie immer noch einen Spiegel wünschen, aber einen, der Git verwendet.

Da die Wartung von hg.python.org nicht notwendig ist, wird das PSF-Infrastrukturkomitee entscheiden, ob es Zeit und Ressourcen aufwenden möchte, um es am Laufen zu halten. Sie können auch entscheiden, ob sie einen Git-Spiegel auf der PSF-Infrastruktur hosten möchten.

Abhängig von der getroffenen Entscheidung werden entweder andere Hilfs-Repositories zur Migration gezwungen oder sie können sich entscheiden, einfach auf hg.python.org zu bleiben.

Git CLI-Befehle zum Committen eines Pull Requests nach cpython

Da Git [4] für Kernentwickler möglicherweise ein neues Versionskontrollsystem ist, müssen die Befehle, die die Leute ausführen sollen, aufgeschrieben werden. Diese Befehle müssen auch eine lineare Historie beibehalten und gleichzeitig dem Autor des Pull-Requests eine ordnungsgemäße Zuschreibung geben.

Ein weiterer Satz von Befehlen wird auch für die Arbeit mit einer Patch-Datei benötigt, die auf bugs.python.org [5] hochgeladen wird. Hier wird die lineare Historie implizit beibehalten, aber es muss sichergestellt werden, dass die Zuschreibung beibehalten/hinzugefügt wird.

Namen für die Bots

Da das Benennen von Dingen zu epischen Bike-Shedding-Ausmaßen führen kann, wird Brett Cannon den endgültigen Namen der verschiedenen Bots wählen (der Name des Projekts für die Bots selbst kann beliebig sein, dies gilt nur für den Namen, der bei der Eingabe von Befehlen an den Bot oder den Kontonamen verwendet wird). Die Namen müssen von Monty Python stammen, was nur passend ist, da Python nach der Komikertruppe benannt ist.

Abgelehnte Ideen

Trennung von Python 2 und Python 3 Repositories

Es wurde diskutiert, ob separate Repositories für Python 2 und Python 3 gewünscht werden. Die Überlegung war, dass dies die Gesamtgröße des Repositories verkleinern würde, was für Personen mit langsamen Internetverbindungen oder kleinen Bandbreitenbeschränkungen von Vorteil ist.

Am Ende wurde entschieden, dass es logistisch einfacher ist, die gesamte Historie von CPython in einem einzigen Repository zu belassen.

Änderungen an mehreren Releases zuerst im Bugfix-Branch committen

Da der aktuelle Entwicklungsprozess Änderungen zuerst im ältesten Branch vornimmt und dann in den Standard-Branch mergt, kam die Frage auf, ob dieser Workflow beibehalten werden sollte. Am Ende wurde entschieden, dass das Committen im neuesten Branch und das anschließende Cherry-Picking von Änderungen in ältere Branches am besten funktioniert, da die meisten Leute instinktiv vom neuesten Branch aus arbeiten werden und es ein gängiger Workflow bei der Verwendung von Git ist [4].

Cherry-Picking ist auch bot-freundlicher für einen In-Browser-Workflow. Im Merge-Up-Szenario müssten Sie sicherstellen, dass Sie Merge-Konflikte sofort lösen, wenn Sie einen Bot bitten, einen Merge durchzuführen, und dieser fehlschlägt, wenn Sie den Haupt-Commit weiterhin zulassen, sonst müssten Sie den gesamten Commit verschieben, bis alle Merges behandelt werden können. Mit einem Cherry-Picking-Workflow kann der Haupt-Commit fortgesetzt werden, während die Merge-fehlerhaften Cherry-Picks verschoben werden. Dies ermöglicht eine mögliche Verteilung der Arbeit an der Verwaltung von konfliktären Merges.

Zuletzt sollte Cherry-Picking helfen, Merge-Races zu vermeiden. Derzeit dauert es, wenn man an Arbeit über mehrere Branches hinweg arbeitet, Zeit, im älteren Branch zu committen, möglicherweise in einen anderen Klon zu pushen, der den default Branch repräsentiert, die Änderung zu mergen und dann nach oben zu pushen. Cherry-Picking sollte dies entkoppeln, sodass Sie Ihre Multi-Branch-Änderungen nicht überstürzen müssen, da das Cherry-Pick separat durchgeführt werden kann.

Ableitung von Misc/NEWS aus den Commit-Logs

Als Teil der Diskussion rund um Umgang mit Misc/NEWS kam der Vorschlag auf, die Datei aus den Commit-Logs selbst abzuleiten. In diesem Szenario würde die erste Zeile einer Commit-Nachricht als Neueintrag für die Änderung genommen. Eine Heuristik, die bestimmt, ob eine Änderung einen Neueintrag rechtfertigt, würde verwendet, z. B. ob eine Issue-Nummer aufgeführt ist.

Diese Idee wurde abgelehnt, da einige Kernentwickler es vorziehen, einen Neueintrag getrennt von der Commit-Nachricht zu schreiben. Das Argument ist, dass die erste Zeile einer Commit-Nachricht im Vergleich zu der eines Neueintrags unterschiedliche Anforderungen an Kürze, Inhalt usw. hat.

Ableitung von Misc/NEWS von bugs.python.org

Eine abgelehnte Lösung für das Problem der NEWS-Datei war, den Eintrag auf bugs.python.org [5] anzugeben. Dies würde bedeuten, dass ein als „gelöst“ markiertes Problem nicht geschlossen werden könnte, bis ein Neueintrag im Feld „News“ im Issue-Tracker hinzugefügt wird. Der Vorteil der Verknüpfung des Neueintrags mit dem Problem ist, dass sichergestellt wird, dass alle Änderungen, die einen Neueintrag wert sind, ein entsprechendes Problem haben. Es macht auch die Klassifizierung eines Neueintrags automatisch dank des Komponentenfeldes des Problems. Das Feld „Versionen“ des Problems verknüpft auch den Neueintrag mit den betroffenen Python-Releases. Ein Skript würde geschrieben, um bugs.python.org nach relevanten neuen Einträgen für ein Release abzufragen und die Ausgabe zu erstellen, die in das Code-Repository eingecheckt werden muss. Dieser Ansatz ist unabhängig davon, ob ein Commit per CLI oder Bot durchgeführt wurde. Ein Nachteil ist, dass es eine Trennung zwischen dem eigentlichen Commit, der die Änderung vorgenommen hat, und dem Neueintrag gibt, da sie an separaten Orten (in diesem Fall GitHub und bugs.python.org) leben. Das würde bedeuten, dass ein Commit das Erinnern erfordert, zurück zu bugs.python.org zu gehen, um den Neueintrag hinzuzufügen.

Referenzen

Quelle: https://github.com/python/peps/blob/main/peps/pep-0512.rst

Zuletzt geändert: 2025-02-01 08:59:27 GMT