PEP 581 – GitHub Issues für CPython verwenden

Autor:: Mariatta <mariatta at python.org>
BDFL-Delegate:: Barry Warsaw <barry at python.org>
Discussions-To:: Discourse thread
Status:: Final
Typ:: Prozess
Erstellt:: 20. Juni 2018
Post-History:: 07. März 2019
Resolution:: Python-Dev Nachricht

Inhaltsverzeichnis

Zusammenfassung
Begründung
- Warum GitHub?
- Probleme mit Roundup / bpo
Warum nicht GitLab?
Warum kein anderer Issue-Tracker?
Warum sich nicht auf die Verbesserung von Roundup / bpo konzentrieren?
Nachteile von GitHub
Weitere Fragen und Diskussionen
Danksagungen
Referenzen
Urheberrecht

Zusammenfassung

Dieser PEP skizziert die Begründung für die Migration von Pythons Issue-Tracker von Roundup zu GitHub Issues. Siehe PEP 588 für den detaillierten Migrationsplan.

CPythons Entwicklung wurde im Februar 2017 auf GitHub verlagert. Alle anderen Projekte innerhalb der PSF-Organisation werden auf GitHub gehostet und nutzen GitHub Issues. CPython verwendet weiterhin Roundup als Issue-Tracker auf bugs.python.org (bpo) [1].

Warum GitHub?

GitHub bietet viele nützliche Funktionen, die sofort einsatzbereit sind. Einige davon sind bei Roundup / bpo nicht ohne Weiteres verfügbar.

APIs, die zur Erstellung von Integrationen und Automatisierungen verwendet werden können. Es gibt verschiedene bestehende Integrationen und Anwendungen im GitHub Marketplace, die den Workflow unterstützen. Neue Anwendungen lassen sich einfach installieren und aktivieren. Darüber hinaus hatten wir großen Erfolg mit der Entwicklung unserer eigenen GitHub-Bots, wie miss-islington [2], bedevere [3] und the-knights-who-say-ni [4].
Möglichkeit, Screenshots und Debug-Logdateien in GitHub Pull Requests und Issues einzubetten/per Drag & Drop einzufügen.
Administratoren und Kernentwickler können Issues, Kommentare und Pull Requests bearbeiten.
Möglichkeit, über E-Mail auf Issue- und Pull-Request-Konversationen zu antworten.
Unterstützung für Zwei-Faktor-Authentifizierung.
Unterstützung für Markdown und Emoji.
Vorschau-Registerkarte, die anzeigt, wie ein Kommentar gerendert wird, bevor er tatsächlich gepostet wird.
Unterstützung für Abstimmungen über Reaktionen.
Unterstützung für Permalinks [5], die ein einfaches Zitieren und Kopieren & Einfügen von Quellcode ermöglichen. Es ist möglich, Code-Schnipsel auf GitHub automatisch einzubetten, indem ein Permalink eingefügt wird.
Kernentwickler, Freiwillige und die PSF müssen die Issue-Infrastruktur/Website nicht warten, was uns mehr Zeit und Ressourcen für die Entwicklung von Python verschafft.
Möglichkeit, Issues automatisch zu schließen, wenn ein PR zusammengeführt wurde [6].
- Beachten Sie, dass diese Funktion auch in bpo existiert.
Geringere Hürde für Beiträge. Mit über 28 Millionen Nutzern ist es für Open-Source-Beitragende wahrscheinlicher, bereits ein Konto zu haben und mit der GitHub-Oberfläche vertraut zu sein, was den Einstieg in die Mitarbeit erleichtert.
E-Mail-Benachrichtigungen mit Metadaten [7], integriert mit Gmail, was eine systematische Filterung von E-Mails ermöglicht. Während Roundup-E-Mails einige Metadaten enthalten, sind sie nicht so umfangreich.
Zusätzliche Privatsphäre, z. B. die Möglichkeit für den Benutzer, eine E-Mail-Adresse auszublenden, während die Kommunikation mit dem Benutzer über @-Erwähnungen weiterhin möglich ist.

Probleme mit Roundup / bpo

Weniger als fünf Personen warten bpo. Einige davon sind Kernentwickler.
Der Upstream-Roundup-Code ist in Mercurial. Ohne verfügbare CI belastet dies die wenigen bestehenden Maintainer stark bei der Überprüfung, dem Testen und dem Anwenden von Patches. Obwohl es einen inoffiziellen Spiegel von Roundup auf GitHub gibt [8], sind Mercurial-Patches immer noch der Hauptweg, um dazu beizutragen.
Es gibt eine offene Diskussion darüber, den Quellcode von bpo nach GitHub zu verlagern [9]. Wenn der Quellcode von bpo nach GitHub verlagert wird, wird es schwierig, Patches von Upstream zu aktualisieren. Aber solange er in Mercurial ist, ist er schwer zu warten und für neue Beitragende zugänglich zu machen.
In seinem aktuellen Zustand ist das Projekt nicht in der Lage, viele Beiträge von Personen anzunehmen, die nicht bereits mit der Codebasis vertraut sind.
Die Benutzeroberfläche benötigt eine Aktualisierung und Neugestaltung. Es bedarf UX/UI-Forschung, um sie auf dem neuesten Stand der Webstandards, einschließlich Barrierefreiheit, zu halten.
E-Mail-Adressen von Benutzern wurden offengelegt.
- Hinweis: Die Offenlegung von E-Mail-Adressen gegenüber registrierten und angemeldeten Benutzern war eine Entscheidung, die bei der Einrichtung der bpo-Instanz getroffen wurde. Dieses Verhalten wurde nach der Annahme von PEP 581 kürzlich geändert.
Eine REST-API ist derzeit in bpo nicht verfügbar. Es gab ein offenes Ticket in Roundup für die Hinzufügung einer REST-API [10]. Zum Zeitpunkt, als PEP 581 vorgeschlagen wurde, erhielt das Ticket seit 2016 keine Aktivität mehr. Eine REST-API wurde im Februar 2019 in Roundup integriert, ist aber noch nicht in bpo integriert.
Es werden eine Reihe unnötiger E-Mails und Benachrichtigungen gesendet. Ein Beispiel ist die "nosy"-E-Mail, bei der E-Mail-Benachrichtigungen gesendet werden, wann immer sich jemand selbst als "nosy" hinzufügt. Ein Ticket wurde hierfür bereits 2012 bei Upstream-Roundup eingereicht, mit wenig Fortschritt [11]. Obwohl es konfiguriert werden kann, wurde die Anfrage zur Konfiguration nicht beantwortet/ignoriert.
Das Erstellen eines Kontos war mühsam. Es gab Berichte über Personen, die Probleme beim Erstellen von Konten oder beim Anmelden hatten. Einige Beispiele für offene Tickets: "Kommas im Benutzernamen verursachen Fehler in der nosy-Liste" [12], "Es ist ein Fehler aufgetreten.." [13], "Ich erhalte keine Bestätigungs-E-Mail..." [14].

Warum nicht GitLab?

Hätten wir 2017 statt GitHub nach GitLab migriert, wäre dieser PEP mit "GitHub Issues für CPython verwenden" betitelt worden.

Warum kein anderer Issue-Tracker?

Die Verwendung eines anderen Issue-Trackers würde eine weitere Lernkurve erfordern, da man sich an eine andere Oberfläche gewöhnen und diese erlernen müsste. Wir müssten auch lernen und herausfinden, wie wir die Integrationen mit GitHub erstellen.

Durch die Nutzung von GitHub Issues, wo der CPython-Quellcode derzeit gehostet wird und wo Pull Requests stattfinden, bieten wir den Beitragenden und Maintainern eine konsistente Erfahrung, ohne von einer Oberfläche zur anderen springen zu müssen.

Warum sich nicht auf die Verbesserung von Roundup / bpo konzentrieren?

GitHub hat viele Funktionen, die wir mögen und die bereits verfügbar sind. Wir müssen noch zusätzliche Integrationen aufbauen und unsere Bots aktualisieren, aber das ist etwas, das wir bereits tun können.

Um Roundup / bpo wirklich zu verbessern, muss es zunächst nach GitHub migriert und CI und Bots hinzugefügt werden. Soweit ich weiß, gibt es Zögern, da Upstream-Roundup immer noch in Mercurial ist. Jemand, der mit Roundup / bpo vertrauter ist, muss diese Anstrengung vorantreiben. (Ich melde mich nicht freiwillig, tut mir leid).

Ich glaube, der Aufwand für die Erstellung und Wartung von GitHub-Integrationen und Bots ist weitaus geringer als der Aufwand, der benötigt wird, um Roundup auf den neuesten Stand zu bringen und es dann weiter zu warten.

Nachteile von GitHub

GitHub ist nicht der perfekte Issue-Tracker. Mehrere Probleme, auf die wir achten müssen

Angst vor Unsicherheit und Vendor Lock-in. GitHub ist proprietär und es besteht die Gefahr von Vendor Lock-in. Dies ist jedoch ein bestehendes Problem, da die Codebasis von CPython bereits auf GitHub liegt. Dies ist auch kein Problem, das nur CPython betrifft. Als Vorsichtsmaßnahme wird das Repository von CPython auf GitHub seit Juni 2018 täglich gesichert. [15]
Bots kosten Geld und nehmen auch die Zeit von Freiwilligen in Anspruch. Wir würden die Wartungsbelastung von Roundup auf die Bots verlagern. Zumindest konnten wir bisher alle Fehler/Probleme im Zusammenhang mit den Bots/GitHub-APIs schnell, innerhalb von Tagen, statt Monaten oder Jahren beheben. GitHub-APIs sind umfangreich und werden nicht nur von CPythons Bots, sondern auch von der breiteren Python-Community genutzt. Dies macht GitHub-APIs zugänglicher im Vergleich zur Wartung von Roundup/bpo.
Die Nutzung von GitHub könnte den Triaging-Aufwand möglicherweise erhöhen. Dies wurde zuerst als Zulip-Thema [16] angesprochen und auch während des Core Python Sprints im September 2018 [17] erörtert. Einige Lösungen wurden vorgeschlagen und in Betracht gezogen, wie die Einrichtung eines speziellen Triage-Teams [18]. Nach der Annahme von PEP 581 hat GitHub eine neue Triage-Rolle veröffentlicht, die sich derzeit in der Beta-Phase befindet. Die PSF steht in Kontakt mit GitHub, um diese für die Python-Organisation zu aktivieren. Dies wartet auf die Prüfung durch GitHub [19].
Die Nutzung von GitHub könnte es Personen erleichtern, störende oder spamartige Kommentare zu posten. Es stimmt, dass es Vorfälle gab, bei denen Kernentwickler störende Diskussionen auf GitHub moderieren und sperren mussten. Glücklicherweise macht die GitHub-Oberfläche es Kernentwicklern leicht, Diskussionen zu moderieren. Darüber hinaus können Vorfälle an GitHub eskaliert werden.
Das manuelle Bearbeiten von Issue-Vorlagen kann umständlich und fehleranfällig sein. Für die meisten Leute wird das Erstellen von Issues auf GitHub jedoch eine viel bessere Erfahrung sein als das Erstellen von Issues auf bpo. Die zahlreichen Felder und Textfelder zur Auswahl können für Neulinge verwirrend und einschüchternd sein, und es ist nicht möglich, eine Nachricht zu "bearbeiten". Auf GitHub kann der Issue-Ersteller seine Einreichung in der Vorschau anzeigen und seine Fehler nach dem Posten bearbeiten.
bpo verwendet eine Reihe von Feldern, um verschiedene Metadaten anzugeben, und diese sind möglicherweise nicht einfach auf GitHub übertragbar. Der vorgesehene Weg, benutzerdefinierte Metadaten auf GitHub zu handhaben, ist die Verwendung von Labels. Die Details, welche Labels erstellt werden sollen, werden weiter in PEP 588 besprochen.

Zuletzt geändert: 2024-06-02 04:57:49 GMT