Versionskontrollsystem

Derzeit verwenden die Repositories von CPython und unterstützende Repositories Mercurial. Als modernes, verteiltes Versionskontrollsystem hat es uns seit der Migration von Subversion gute Dienste geleistet. Bei der Bewertung des VCS müssen wir jedoch die Fähigkeiten des VCS selbst sowie den Netzwerkeffekt und die Verbreitung in der Community rund um dieses VCS berücksichtigen.

Es gibt hier eigentlich nur zwei echte Optionen: Mercurial und Git. Die technischen Fähigkeiten der beiden Systeme sind weitgehend gleichwertig, daher konzentriert sich diese PEP stattdessen auf ihre sozialen Aspekte.

Es ist nicht möglich, genaue Zahlen über die Anzahl der Projekte oder Personen zu ermitteln, die ein bestimmtes VCS verwenden. Wir können dies jedoch anhand mehrerer Informationsquellen ableiten, welche VCS-Projekte verwenden.

Die Statistiken von Open Hub (ehemals Ohloh) [1] zeigen, dass 37 % der von Open Hub indizierten Repositories Git verwenden (nach Subversion mit 48 % an zweiter Stelle), während Mercurial nur 2 % hat und nur Bazaar mit 1 % übertrifft. Das bedeutet, dass Git auf Open Hub über 18-mal beliebter ist als Mercurial.

Eine weitere Informationsquelle zur VCS-Popularität ist PyPI selbst. Diese Quelle ist stärker auf die Python-Community ausgerichtet, da sie für Python entwickelte Projekte repräsentiert. Leider hat PyPI keinen standardisierten Ort für die Darstellung dieser Informationen, so dass dies eine manuelle Verarbeitung erfordert. Wenn wir unsere Suche auf die Top-100-Projekte auf PyPI (geordnet nach Download-Zahlen) beschränken, können wir feststellen, dass 62 % davon Git verwenden, während 22 % Mercurial und 13 % etwas anderes verwenden. Das bedeutet, dass Git bei den Top-100-Projekten auf PyPI knapp 3-mal beliebter ist als Mercurial.

Diese Zahlen stützen die anekdotische Evidenz für Git als das weitaus beliebtere DVCS für Open-Source-Projekte. Die Wahl des beliebteren VCS hat eine Reihe positiver Vorteile.

Für neue Mitwirkende erhöht es die Wahrscheinlichkeit, dass sie die Grundlagen von Git bereits durch die Arbeit an einem anderen Projekt gelernt haben, oder wenn sie Git gerade erst lernen, dass sie dieses Wissen auf andere Projekte anwenden können. Darüber hinaus bedeutet eine größere Community mehr Leute, die Anleitungen schreiben, Fragen beantworten und Artikel über Git verfassen, was es für neue Benutzer einfacher macht, Antworten und Informationen über das Werkzeug zu finden, das sie lernen und verwenden möchten. Angesichts seiner Beliebtheit gibt es möglicherweise auch mehr Hilfswerkzeuge, die *um* Git herum geschrieben sind. Dies erhöht die Optionen für alles, von GUI-Clients über Hilfsskripte bis hin zum Repository-Hosting usw.

Darüber hinaus verbietet die Einführung von Git als vorgeschlagenes Backend-Repository-Format nicht die Verwendung von Mercurial durch Fans dieses VCS! Mercurial-Benutzer haben das [2] Plugin, mit dem sie von einem Git-Server mit dem Mercurial-Frontend aus pushen und pullen können. Es ist ein gut gewartetes und hochfunktionales Plugin, das von Mercurial-Benutzern gut angenommen zu werden scheint.

Repository-Hosting

Wo und wie die offiziellen Repositories für CPython gehostet werden, wird in gewisser Weise durch die Wahl des VCS bestimmt. Mit Git gibt es mehrere Optionen. Tatsächlich können, sobald das Repository in Git gehostet wird, Branches an vielen Orten gespiegelt werden, auf vielen kostenlosen, offenen und proprietären Code-Hosting-Seiten.

Es ist für CPython immer noch wichtig, ein einziges, offizielles Repository zu übernehmen, mit einem Web-Frontend, das viele bequeme und gängige Interaktionen ermöglicht, die vollständig über das Web abgewickelt werden, ohne immer lokale VCS-Manipulationen zu erfordern. Diese Interaktionen umfassen mindestens Code-Review mit Inline-Kommentaren, Branch-Diffing, CI-Integration und Auto-Merging.

Diese PEP schlägt die Übernahme einer [3] Instanz vor, die innerhalb der python.org-Domäne betrieben wird, für die PSF und das Python-Infrastrukturteam zugänglich ist und unter deren ultimativer Kontrolle steht, aber von GitLab, Inc. gespendet, gehostet und hauptsächlich gewartet wird.

Warum GitLab? Weil es ein voll funktionsfähiges Git-Hosting-System ist, das moderne Web-Interaktionen, Software-Workflows und CI-Integration bietet. GitLabs Community Edition (CE) ist Open-Source-Software und steht somit den Prinzipien der CPython-Community nahe.

Code-Review

Derzeit verwendet CPython einen benutzerdefinierten Fork von Rietveld, der so modifiziert wurde, dass er nicht auf Google App Engine läuft und der derzeit nur von einer Person wirklich gewartet wird. Es fehlen ihm gängige Funktionen, die in vielen modernen Code-Review-Tools vorhanden sind.

Diese PEP schlägt vor, die integrierten Merge Requests und Online-Code-Review-Funktionen von GitLab zu nutzen, um die Überprüfung aller vorgeschlagenen Änderungen zu erleichtern.

GitLab Merge Requests

Der normale Workflow für ein GitLab-gehostetes Projekt besteht darin, einen *Merge Request* einzureichen, der fordert, dass ein Feature- oder Bugfix-Branch in einen Ziel-Branch gemerged wird, normalerweise einer oder mehrere der stabilen Wartungs-Branches oder der Master-Branch für neue Features der nächsten Version. GitLabs Merge Requests sind in Form und Funktion den GitHub Pull Requests ähnlich, so dass jeder, der mit letzteren bereits vertraut ist, die ersteren sofort nutzen kann.

Nach der Einreichung kann eine Konversation über die Änderung zwischen dem Einreicher und dem Gutachter geführt werden. Dies umfasst sowohl allgemeine Kommentare als auch Inline-Kommentare, die an einer bestimmten Zeile des Diffs zwischen Quell- und Ziel-Branches angebracht sind. Projekte können auch so konfiguriert werden, dass sie automatisch kontinuierliche Integration auf dem eingereichten Branch ausführen, deren Ergebnisse auf der Merge Request-Seite gut sichtbar sind. So können sowohl der Gutachter als auch der Einreicher sofort die Ergebnisse der Tests sehen, was es viel einfacher macht, nur Branches mit bestandenen Tests zu landen. Jeder neue Push zum Quell-Branch (z. B. um auf Feedback eines Kommentators zu reagieren oder einen fehlschlagenden Test zu beheben) führt zu einem neuen CI-Durchlauf, so dass der Status der Anfrage immer dem letzten Commit entspricht.

Merge Requests haben einen ziemlich großen Vorteil gegenüber dem älteren Modell "Patch an einen Bugtracker senden". Sie ermöglichen es Entwicklern, vollständig innerhalb des VCS mit Standard-VCS-Tools zu arbeiten, ohne die Erstellung einer Patch-Datei oder das Ermitteln des richtigen Speicherorts zum Hochladen des Patches zu erfordern. Dies senkt die Hürde für die Einreichung einer Änderung zur Überprüfung.

Merge Requests sind wesentlich einfacher zu überprüfen. Sie bieten beispielsweise schöne, syntaktisch hervorgehobene Diffs, die entweder in einer einheitlichen oder nebeneinanderliegenden Ansicht betrieben werden können. Sie erlauben Inline-Kommentare und Kommentare zum Merge Request als Ganzes und präsentieren diese auf eine schöne, einheitliche Weise, die auch Kommentare ausblendet, die nicht mehr zutreffen. Kommentare können ausgeblendet und angezeigt werden.

Das eigentliche Mergen eines Merge Requests ist recht einfach, wenn der Quell-Branch sauber auf den Ziel-Branch angewendet werden kann. Ein Kern-Gutachter muss lediglich den "Merge"-Button drücken, damit GitLab den Merge automatisch durchführt. Der Quell-Branch kann optional rebased werden, und nach Abschluss des Merges kann der Quell-Branch automatisch gelöscht werden.

GitLab bietet auch einen guten Workflow für die Einreichung von Pull Requests an ein Projekt vollständig über seine Weboberfläche. Dies würde es der Python-Dokumentation ermöglichen, "Auf GitLab bearbeiten"-Buttons auf jeder Seite zu haben, und Leute, die Tippfehler, Ungenauigkeiten entdecken oder einfach nur Verbesserungen an den gerade gelesenen Docs vornehmen möchten. Sie können einfach auf diesen Button klicken und erhalten einen In-Browser-Editor, der es ihnen ermöglicht, Änderungen vorzunehmen und einen Merge Request einzureichen, alles bequem von ihrem Browser aus.

X ist nicht in Python geschrieben

Eine Funktion, die die aktuelle Toolchain (Mercurial, Rietveld) hat, ist, dass die Hauptsprache für alle Komponenten in Python geschrieben ist. Diese PEP konzentriert sich mehr auf die *besten* Werkzeuge für die jeweilige Aufgabe und nicht unbedingt auf die *besten* Werkzeuge, die zufällig in Python geschrieben sind. Freiwilligenzeit ist die wertvollste Ressource für jedes Open-Source-Projekt, und wir können diese Zeit am besten respektieren und nutzen, indem wir uns auf die Vorteile und Nachteile der Werkzeuge selbst konzentrieren, anstatt auf die Sprache, in der ihre Autoren sie zufällig geschrieben haben.

Eine Bedenken ist die Möglichkeit, Werkzeuge zu modifizieren, um sie für uns funktionsfähig zu machen. Ein Ziel hier ist jedoch, *keine* Software für uns zu modifizieren, sondern uns an einen standardisierteren Workflow anzupassen. Diese Standardisierung zahlt sich in der Fähigkeit aus, Werkzeuge sofort wiederverwenden zu können, wodurch Entwicklerzeit frei wird, um tatsächlich an Python selbst zu arbeiten, und Wissensaustausch zwischen Projekten ermöglicht wird.

Wenn wir jedoch die Werkzeuge modifizieren müssen, ist Git selbst größtenteils in C geschrieben, wie auch CPython selbst. Es können auch Befehle für es in jeder Sprache geschrieben werden, einschließlich Python. GitLab selbst ist größtenteils in Ruby geschrieben, und da es sich um Open-Source-Software handelt, hätten wir die Möglichkeit, Merge Requests an die Upstream Community Edition einzureichen, wenn auch in einer Sprache, die den meisten Python-Programmierern möglicherweise unbekannt ist.

Mercurial ist besser als Git

Ob Mercurial oder Git technisch besser ist, ist eine sehr subjektive Meinung. Diese PEP gibt nicht an, ob die Mechaniken von Git oder Mercurial besser sind, sondern konzentriert sich stattdessen auf den Netzwerkeffekt, der für beide Optionen verfügbar ist. Obwohl diese PEP den Wechsel zu Git vorschlägt, sind Mercurial-Benutzer nicht völlig außen vor. Durch die Verwendung der hg-git-Erweiterung für Mercurial ist die Arbeit mit serverseitigen Git-Repositories recht einfach und unkompliziert.

Der CPython-Workflow ist zu kompliziert

Eine Stimmung, die aus früheren Diskussionen hervorgegangen ist, war, dass das Multi-Branch-Modell von CPython für GitLab-Style-Merge-Requests zu kompliziert sei. Diese PEP widerspricht dieser Aussage.

Derzeit erfordert eine bestimmte Änderung die manuelle Erstellung eines Patches für 2.7 und 3.x, was sich in dieser Hinsicht nicht ändern wird.

Wenn jemand einen Fix für den aktuellen stabilen Branch (z. B. 3.5) einreicht, kann der Merge Request-Workflow verwendet werden, um einen Request zum Mergen des aktuellen stabilen Branches in den Master-Branch zu erstellen, vorausgesetzt, es gibt keine Merge-Konflikte. Wie immer müssen Merge-Konflikte manuell und lokal aufgelöst werden. Da Entwickler auch die *Option* haben, den Merge lokal durchzuführen, bietet dies eine Verbesserung gegenüber der aktuellen Situation, in der der Merge *immer* lokal stattfinden muss.

Für Fixes im aktuellen Entwicklungs-Branch, die auch auf stabile Release-Branches angewendet werden müssen, ist es in vielen Situationen möglich, lokal Cherry-Picks durchzuführen und die Änderung auf andere Branches anzuwenden, wobei für jeden stabilen Branch Merge Requests eingereicht werden. Es ist auch möglich, einfach Cherry-Picks durchzuführen und den Merge lokal abzuschließen. Dies alles wird mit Standard-Git-Befehlen und -Techniken erreicht, mit dem Vorteil, dass alle solchen Änderungen die Überprüfungs- und CI-Test-Workflows durchlaufen können, selbst für Merges zu stabilen Branches. Kleinere Änderungen können einfach im GitLab-Web-Editor vorgenommen werden.

Kein System kann alle Komplexitäten, die mit der Wartung mehrerer langjähriger Branches verbunden sind, verbergen. Das Einzige, was die Toolchain tun kann, ist, die Einreichung und das Committen von Änderungen so einfach wie möglich zu gestalten.