Versionskontrollsystem

Die erste Entscheidung, die getroffen werden muss, ist das VCS des primären serverseitigen Repositories. Derzeit verwendet das CPython-Repository sowie eine Reihe von unterstützenden Repositories Mercurial. Bei der Bewertung des VCS müssen wir die Fähigkeiten des VCS selbst sowie den Netzwerkeffekt und den Bekanntheitsgrad der Community rund um dieses VCS berücksichtigen.

Es gibt wirklich nur zwei reale Optionen dafür: Mercurial und Git. Zwischen beiden sind die technischen Fähigkeiten weitgehend gleichwertig. Aus diesem Grund wird diese PEP die technischen Argumente über das VCS-System weitgehend ignorieren und sich stattdessen auf die sozialen Aspekte konzentrieren.

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

Die Statistiken von Open Hub (ehemals Ohloh) [1] zeigen, dass 37 % der von Open Hub indizierten Repositories Git verwenden (nur zweitrangig hinter SVN mit 48 %), während Mercurial nur 2 % hat (nur Bazaar mit 1 % schlagend). Dies macht Git auf Open Hub etwas mehr als 18 Mal so beliebt wie Mercurial.

Eine weitere Informationsquelle über die Beliebtheit der verschiedenen VCS ist PyPI selbst. Diese Quelle richtet sich stärker an die Python-Community selbst, da sie für Python entwickelte Projekte repräsentiert. Leider hat PyPI keinen Standardort für die Darstellung dieser Informationen, sodass dies eine manuelle Verarbeitung erfordert. Wenn wir unsere Suche auf die Top 100 Projekte auf PyPI (geordnet nach Downloadzahlen) beschränken, können wir sehen, dass 62 % davon Git verwenden, während 22 % Mercurial und 13 % etwas anderes verwenden. Dies macht Git für die Top 100 Projekte auf PyPI knapp 3 Mal so beliebt wie Mercurial.

Offensichtlich ist Git nach diesen Zahlen mit Abstand das beliebtere DVCS für Open-Source-Projekte, und die Wahl des beliebteren VCS hat eine Reihe von positiven Vorteilen.

Für neue Mitwirkende erhöht es die Wahrscheinlichkeit, dass sie die Grundlagen von Git bereits im Rahmen der Arbeit an einem anderen Projekt gelernt haben, oder dass sie, wenn sie Git gerade lernen, 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 einen neuen Benutzer einfacher macht, Antworten und Informationen über das Tool zu finden, das er lernen möchte.

Ein weiterer Vorteil ist, dass aufgrund einer größeren Community mehr Tools *darum herum* geschrieben werden. Dies erhöht die Optionen für alles, von GUI-Clients über Hilfsskripte bis hin zu Repository-Hosting usw.

Repository-Hosting

Diese PEP schlägt die Zulassung von GitHub Pull Requests vor, jedoch hat GitHub keine Möglichkeit, Pull Requests für ein Repository einzureichen, das nicht auf GitHub gehostet wird. Diese PEP schlägt auch vor, dass zusätzlich zu GitHub Pull Requests die Differential-App von Phabricator verwendet werden kann, um vorgeschlagene Änderungen einzureichen, und Phabricator *erlaubt* das Einreichen von Änderungen für ein Repository, das nicht auf Phabricator gehostet wird.

Aus diesem Grund schlägt diese PEP die Nutzung von GitHub als kanonischen Speicherort des Repositories vor, mit einem schreibgeschützten Spiegel auf Phabricator. Sollte GitHub zu irgendeinem Zeitpunkt in der Zukunft nicht mehr gewünscht sein, kann das Repository-Hosting einfach vollständig auf Phabricator verschoben werden und die Möglichkeit, GitHub Pull Requests zu akzeptieren, entfällt.

Zusätzlich zum Hosting der Repositories auf Github wird eine schreibgeschützte Kopie aller Repositories auch auf der PSF-Infrastruktur gespiegelt.

Code-Review

Derzeit verwendet CPython eine benutzerdefinierte Abzweigung (Fork) von Rietveld, die modifiziert wurde, um nicht auf Google App Engine zu laufen, was derzeit nur von einer Person gewartet werden kann. Außerdem fehlen Funktionen, die in vielen modernen Code-Review-Tools vorhanden sind.

Diese PEP schlägt vor, sowohl Github Pull Requests als auch Phabricator-Änderungen zuzulassen, um Änderungen vorzuschlagen und Code zu überprüfen. Sie schlägt beide vor, damit Mitwirkende auswählen können, welches Tool ihnen am besten ermöglicht, Änderungen einzureichen, und Gutachter sich auf die Überprüfung von Änderungen in den Tools konzentrieren können, die sie am besten mögen.

X ist nicht in Python geschrieben

Ein Merkmal, das die aktuelle Werkzeugkombination (Mercurial, Rietveld) aufweist, ist, dass die Hauptsprache aller Komponenten in Python geschrieben ist. Diese PEP vertritt die Meinung, dass wir uns auf die *besten* Werkzeuge für die jeweilige Aufgabe konzentrieren sollten und nicht auf die *besten* Werkzeuge, die zufällig in Python geschrieben sind. Die ehrenamtliche Zeit ist eine wertvolle Ressource für jedes Open-Source-Projekt, und wir können diese Zeit am besten respektieren und nutzen, indem wir uns auf die Vor- und Nachteile der Werkzeuge selbst konzentrieren und nicht auf die Sprache, in der ihre Autoren sie zufällig geschrieben haben.

Ein Anliegen ist die Möglichkeit, Werkzeuge anzupassen, um für uns zu funktionieren. Eines der Ziele hier ist es jedoch, Software *nicht* anzupassen, um für uns zu funktionieren, sondern uns selbst an einen standardmäßigeren Workflow anzupassen. Diese Standardisierung zahlt sich in der Möglichkeit aus, Werkzeuge sofort wiederverwenden zu können, wodurch Entwicklungszeit frei wird, um tatsächlich an Python selbst zu arbeiten, sowie den Wissensaustausch zwischen Projekten zu ermöglichen.

Wenn wir jedoch die Werkzeuge modifizieren müssen, ist Git selbst größtenteils in C geschrieben, genau wie CPython selbst. Es kann auch Befehle enthalten, die in jeder Sprache geschrieben sind, einschließlich Python. Phabricator ist in PHP geschrieben, was eine recht gängige Sprache in der Web-Welt ist und relativ leicht zu erlernen ist. GitHub selbst ist größtenteils in Ruby geschrieben, aber da es nicht Open Source ist, gibt es keine Möglichkeit, es zu modifizieren, sodass seine Implementierungssprache völlig bedeutungslos ist.

GitHub ist nicht Free/Open Source

GitHub ist ein wichtiger Teil dieses Vorschlags und jemand, der eher zu Ideologie als zu Pragmatismus neigt, könnte sich aus diesem Grund gegen diese PEP aussprechen. Diese PEP vertritt die Meinung, dass die Nutzung ausschließlich freier/Open-Source-Software zwar eine attraktive Idee und ein edles Ziel ist, aber die Zeit der Mitwirkenden durch die Bereitstellung guter, gut gewarteter Werkzeuge, die sie entweder bereits kennen oder, wenn sie sie lernen, auf andere Projekte anwenden können, eine wichtigere Angelegenheit ist als die Behandlung, ob etwas Free/Open Source ist, als harte Anforderung.

Die Geschichte hat uns jedoch gezeigt, dass manchmal wohlwollende proprietäre Unternehmen aufhören können, wohlwollend zu sein. Dies wird auf verschiedene Weise abgefedert.

• Wir nutzen den GitHub Issue Tracker nicht, sowohl weil er für CPython nicht leistungsfähig genug ist, als auch weil für das primäre CPython-Repository die Möglichkeit, unsere Issues zu nehmen und sie woanders hinzulegen, wenn wir GitHub jemals verlassen müssen, davon abhängt, dass GitHub weiterhin API-Zugriff gewährt.
• Wir nutzen den GitHub Pull Request-Workflow, jedoch leben alle diese Änderungen innerhalb von Git. Ein Spiegel der GitHub-Repositories kann also leicht alle diese Pull Requests enthalten. Wir würden potenziell alle Kommentare verlieren, wenn GitHub plötzlich "böse" würde, aber die Änderungen selbst würden immer noch existieren.
• Wir nutzen die GitHub-Repository-Hosting-Funktion, aber da dies nur Git ist, ist ein Umzug von GitHub so einfach wie das Pushen des Repositories an einen anderen Ort. Die Datenportabilität für das Repository selbst ist extrem hoch.
• Wir nutzen auch Phabricator, um eine Alternative für Personen anzubieten, die GitHub nicht nutzen möchten. Dies dient auch als Fallback-Option, die bereits vorhanden ist, wenn wir GitHub jemals nicht mehr nutzen müssen.

Die Abhängigkeit von GitHub bringt eine Reihe von Vorteilen mit sich, die über die Vorteile der Plattform selbst hinausgehen. Da es sich um ein kommerziell unterstütztes Unternehmen handelt, gibt es Vollzeitmitarbeiter, die für die Wartung seiner Dienste verantwortlich sind. Dazu gehört die Sicherstellung, dass sie hochfahren, dass sie für verschiedene Sicherheitslücken gepatcht sind und dass die Software und Infrastruktur im Laufe der Zeit weiter verbessert werden.

Mercurial ist besser als Git

Ob Mercurial oder Git technisch besser ist, ist eine sehr subjektive Meinung. Diese PEP gibt nicht an, ob die Mechanik von Git oder Mercurial besser ist, sondern konzentriert sich stattdessen auf den Netzwerkeffekt, der für beide Optionen verfügbar ist. Da diese PEP den Wechsel zu Git vorschlägt, bleiben die Leute, die Mercurial bevorzugen, außen vor. Diese Benutzer können jedoch weiterhin mit Mercurial arbeiten, indem sie die [2] hg-git-Erweiterung für Mercurial verwenden, mit der es mit einem Repository arbeiten kann, das serverseitig Git ist.

CPython Workflow ist zu kompliziert

Ein Gefühl, das aus früheren Diskussionen kam, war, dass das Mehrzweig-Modell von CPython für Github Pull Requests zu kompliziert sei. Diese PEP ist der Überzeugung, dass diese Aussage nicht zutreffend ist.

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

Wenn jemand eine Korrektur für den aktuellen stabilen Branch (derzeit 3.4) einreicht, kann der GitHub Pull Request-Workflow verwendet werden, um im Browser einen Pull Request zu erstellen, um den aktuellen stabilen Branch in den Master-Branch zu mergen (vorausgesetzt, es gibt keine Merge-Konflikte). Bei einem Merge-Konflikt muss dieser lokal behandelt werden. Dies bietet eine Verbesserung gegenüber der aktuellen Situation, in der der Merge immer lokal erfolgen muss.

Wenn schließlich jemand eine Korrektur für den aktuellen Entwicklungsbranch einreicht, muss diese manuell in den stabilen Branch übernommen werden, wenn sie auch dort enthalten sein soll. Dies muss ebenfalls lokal im neuen Workflow erfolgen, könnte aber bei kleineren Änderungen einfach im GitHub Web-Editor erfolgen.

Wenn man sich das ansieht, glaube ich nicht, dass *irgendein* System die Komplexität, die mit der Wartung mehrerer langlaufender Branches verbunden ist, verbergen kann. Das Einzige, was das Werkzeug tun kann, ist, es so einfach wie möglich zu machen, Änderungen einzureichen.