Zusammenfassung

Dieses PEP schlägt eine Liste von Verbesserungen vor, um bugs.python.org für Mitwirkende und Kernentwickler nutzbarer zu machen. Dieses PEP diskutiert auch, warum die Beibehaltung von Roundup der Umstellung auf GitHub Issues, wie in PEP 581 vorgeschlagen, vorzuziehen ist.

Entscheidung

25.06.2020: Mit der Annahme von PEP 581 schreitet der Umzug zu GitHub für Issues voran. Dieses PEP wird als zurückgezogenes informatives PEP markiert.

Motivation

Am 14. Mai 2019 wurde PEP 581 ohne viel öffentliche Diskussion und ohne klaren Konsens akzeptiert. Das PEP enthält sachliche Fehler und geht nicht auf einige der Probleme ein, die die Migration zu GitHub Issues mit sich bringen könnte.

Angesichts des Umfangs der Migration, des erforderlichen Arbeitsaufwands und der negativen Auswirkungen auf den Workflow während der Übergangsphase sollte diese Entscheidung neu bewertet werden.

Vorteile von Roundup gegenüber GitHub Issues

Dieser Abschnitt erörtert Gründe, warum Roundup GitHub Issues vorgezogen werden sollte und Roundup-Funktionen, die auf GitHub Issues nicht verfügbar sind.

• Roundup ist der Status quo. Roundup ist seit Jahren ein integraler Bestandteil des CPython-Workflows. Es ist ein stabiles Produkt, das getestet und angepasst wurde, um unseren Bedürfnissen im Zuge der Workflow-Entwicklung gerecht zu werden.

  Es ist möglich, es schrittweise zu verbessern und die Störungen zu vermeiden, die ein Wechsel zu einem anderen System unweigerlich in den Workflow bringen würde.

• Open-Source und Python-basiert. Roundup ist ein Open-Source-Projekt und in Python geschrieben. Indem wir es nutzen und unterstützen, unterstützen wir auch das Python-Ökosystem. Mehrere für bpo entwickelte Funktionen wurden im Laufe der Jahre auch in das Upstream-Roundup portiert.
• Vollständig anpassbar. Roundup kann (und wurde) vollständig an unsere Bedürfnisse angepasst werden.
• Feingranulare Zugriffskontrolle. Roundup ermöglicht die Erstellung verschiedener Rollen mit unterschiedlichen Berechtigungen (z. B. Erstellen, Anzeigen, Bearbeiten usw.) für jede einzelne Eigenschaft, und Benutzer können mehrere Rollen haben.
• Flexible Benutzeroberfläche. Obwohl die Roundup-Benutzeroberfläche veraltet aussehen mag, ist sie praktisch und flexibel.

  Auf der Issue-Seite haben beispielsweise alle Felder (z. B. Titel, Typ, Versionen, Status, verknüpfte Dateien und PRs usw.) geeignete UI-Elemente (Eingabefelder, Dropdowns, Tabellen usw.), die einfach einzustellen sind und auch eine bequeme Möglichkeit bieten, Informationen über das Issue auf einen Blick zu erhalten. Die Anzahl der Felder, ihre Werte und das verwendete UI-Element sind ebenfalls vollständig anpassbar. GitHub bietet nur Labels.

  Die Liste der Issues zeigt die Issues in einer kompakten und gut lesbaren Tabelle mit separaten Spalten für verschiedene Felder an. Zum Vergleich: Roundup listet 50 Issues auf einem Bildschirm, während GitHub zwei Bildschirme benötigt, um 25 Issues anzuzeigen.

• Erweiterte Suche. Roundup bietet eine präzise Möglichkeit zur Suche und Filterung durch die Verwendung beliebiger Kombinationen von Issue-Feldern. Es ist auch möglich, die Anzahl der Ergebnisse und die in der Tabelle angezeigten Felder sowie die Sortierung und Gruppierung (bis zu zwei Ebenen) anzupassen.

  bpo bietet auch vordefinierte Zusammenfassungen (z. B. „Von Ihnen erstellt“, „Ihnen zugewiesen“ usw.) und ermöglicht die Erstellung benutzerdefinierter Suchanfragen, die bequem über die Seitenleiste abgerufen werden können.

• Autocomplete für die „Nosy List“. Die „Nosy List“ verfügt über eine Autocomplete-Funktion, die Maintainer und Experten vorschlägt. Die Vorschläge werden automatisch aktualisiert, wenn sich der Expertenindex ändert.
• Abhängigkeiten und Nachfolger. Roundup ermöglicht die Angabe von Abhängigkeiten, die erfüllt sein müssen, bevor die aktuellen Issues geschlossen werden können, und eines Nachfolger-Issues, um Duplikate einfach zu kennzeichnen (z. B. bpo-12078). Die Liste der Abhängigkeiten kann auch verwendet werden, um Meta-Issues zu erstellen, die mehrere andere Unter-Issues referenzieren (z. B. bpo-26865).

Verbesserung von Roundup

Dieser Abschnitt listet einige der von PEP 581 genannten Probleme und andere gewünschte Funktionen auf und diskutiert, wie sie durch die Verbesserung von Roundup und/oder unserer Instanz implementiert werden können.

• REST-API-Unterstützung. Eine REST-API erleichtert die Integration mit anderen Diensten und die Entwicklung neuer Werkzeuge und Anwendungen.

  Upstream-Roundup unterstützt jetzt eine REST-API. Durch die Aktualisierung des Trackers wird die REST-API verfügbar.

• GitHub-Login-Unterstützung. Dies ermöglicht es Benutzern, sich bei bugs.python.org (bpo) anzumelden, ohne ein neues Konto erstellen zu müssen. Es löst auch Probleme mit Bestätigungs-E-Mails, die als Spam markiert werden, und bietet Zwei-Faktor-Authentifizierung.

  Ein Patch zur Hinzufügung dieser Funktionalität ist bereits verfügbar und wird zum Zeitpunkt der Erstellung integriert.

• Markdown-Unterstützung und Nachrichten-Vorschau und -Bearbeitung. Diese Funktion ermöglicht die Verwendung von Markdown in Nachrichten und die Möglichkeit, die Nachricht vor der Einreichung in der Vorschau anzuzeigen und sie danach zu bearbeiten.

  Dies kann getan werden, erfordert aber einige Arbeit. Mögliche Lösungen wurden auf der roundup-devel Mailingliste vorgeschlagen.

• Schaltfläche „Mich aus der Nosy List entfernen“. Füge auf der Issue-Seite eine Schaltfläche hinzu, um sich selbst aus der „Nosy List“ zu entfernen.

  Diese Funktion wird während GSoC 2019 hinzugefügt.

• Mobilfreundliches Theme. Das aktuelle Theme von bugs.python.org sieht veraltet aus und funktioniert nicht gut mit mobilen Browsern.

  Es wird ein mobilfreundliches Theme hinzugefügt, das moderner, aber dennoch vertraut ist.

• Antwortfeld nahe der letzten Nachricht verschieben. Das Antwortfeld befindet sich oben auf der Seite, während sich die letzte Nachricht unten befindet.

  Das Antwortfeld kann nach der letzten Nachricht verschoben oder dupliziert werden.

• Echtzeit-Updates. Wenn ein anderer Benutzer Änderungen an einem Issue vornimmt, sollten diese in Echtzeit angezeigt werden.

  Dies kann mithilfe der REST-API erreicht werden.

• PR-Link zu BPO-E-Mails hinzufügen. Derzeit enthalten BPO-E-Mails keine Links zu den entsprechenden PRs.

  Ein Patch ist verfügbar, um den Inhalt der BPO-E-Mails zu ändern.

  components: +Tkinter
  versions: +Python 3.4
  pull_requests: +42
  

  zu

  components: +Tkinter
  versions: +Python 3.4
  pull_request: https://github.com/python/cpython/pull/341
  

• Python 3-Unterstützung. Die Verwendung von Python 3 erleichtert die Wartung.

  Upstream-Roundup unterstützt jetzt Python 3. Durch die Aktualisierung des Trackers können wir zu Python 3 wechseln. Die Instanzen müssen ebenfalls aktualisiert werden.

• Upstream-Roundup verwenden. Wir verwenden derzeit einen Fork von Roundup mit einigen Modifikationen, insbesondere der GitHub-Integration. Wenn diese in das Upstream-Projekt portiert wird, können wir Upstream-Roundup verwenden, ohne unseren Fork warten zu müssen.

PEP 581 Probleme

Dieser Abschnitt behandelt einige Fehler und Ungenauigkeiten, die in PEP 581 gefunden wurden.

Der Abschnitt „Why GitHub?“ von PEP 581 listet Funktionen auf, die derzeit auf GitHub Issues verfügbar sind, aber nicht auf Roundup. Einige dieser Funktionen werden derzeit unterstützt.

• „Möglichkeit, auf Issue- und Pull-Request-Konversationen per E-Mail zu antworten.“
  • Die Möglichkeit, per E-Mail zu antworten, ist seit Beginn eine Kernfunktion von Roundup. Es ist auch möglich, neue Issues zu erstellen oder bestehende zu schließen, Felder festzulegen oder zu ändern und Anhänge hinzuzufügen.
• „E-Mail-Benachrichtigungen mit Metadaten, integriert mit Gmail, die eine systematische Filterung von E-Mails ermöglichen.“
  • Von Roundup gesendete E-Mails enthalten Metadaten, die für die Filterung verwendet werden können.
• „Zusätzliche Privatsphäre, z. B. dem Benutzer die Wahl zu geben, eine E-Mail-Adresse zu verbergen und dennoch die Kommunikation mit dem Benutzer über @-Erwähnungen zu ermöglichen.“
  • E-Mail-Adressen sind standardmäßig für Benutzer, die nicht registriert sind, verborgen. Registrierte Benutzer können die Adressen anderer Benutzer sehen, da wir den Tracker so konfiguriert haben, dass er sie anzeigt. Dies kann bei Bedarf einfach geändert werden. Benutzer können weiterhin zur „Nosy List“ hinzugefügt werden, indem sie ihren Benutzernamen verwenden, auch wenn ihre Adresse verborgen ist.
• „Möglichkeit, Issues automatisch zu schließen, wenn ein PR zusammengeführt wurde.“
  • Die GitHub-Integration von Roundup schließt automatisch Issues, wenn ein Commit, der „fixes issue <id>“ enthält, zusammengeführt wird. (Alternative Schreibweisen wie „closes“ oder „bug“ werden ebenfalls unterstützt.) Siehe diese Nachricht als aktuelles Beispiel für diese Funktion.
• „Unterstützung für Permalinks, die einfaches Zitieren und Kopieren/Einfügen von Quellcode ermöglichen.“
  • Roundup verfügt über Permalinks für Issues, Nachrichten, Anhänge usw. Darüber hinaus ermöglicht Roundup das einfache Korrigieren fehlerhafter URLs in Nachrichten (z. B. wenn sich das Code-Hosting ändert).
• „Kernentwickler, Freiwillige und die PSF müssen die Issue-Infrastruktur/-Website nicht warten, was uns mehr Zeit und Ressourcen gibt, uns auf die Entwicklung von Python zu konzentrieren.“
  • Dies ist zwar teilweise richtig, erfordert aber zusätzliche Ressourcen, um Bots zu schreiben und zu warten.

    In einigen Fällen sind Bots erforderlich, um die fehlenden Funktionen von GitHub zu umgehen, anstatt sie zu erweitern. Dieser Webhook wurde speziell geschrieben, um die E-Mail-Integration von GitHub zu umgehen.

    Das Aktualisieren unserer Bots, um mit Änderungen in der GitHub-API Schritt zu halten, verursacht ebenfalls Wartungskosten. Dieser kürzliche Vorfall, der durch GitHub verursacht wurde, dauerte zwei Tage bis zur Behebung.

    Darüber hinaus müssen wir Roundup weiterhin für bpo (auch wenn es schreibgeschützt wird) und für die anderen Tracker, die wir derzeit hosten/warten ( Jython und Roundup), pflegen.

Der Abschnitt „Issues with Roundup / bpo“ von PEP 581 listet einige Probleme auf, die bereits behoben wurden.

• „Der Upstream-Roundup-Code befindet sich in Mercurial. Ohne verfügbare CI-Tests stellt dies eine schwere Belastung für die wenigen vorhandenen Maintainer dar, was die Überprüfung, das Testen und die Anwendung von Patches betrifft.“
  • Obwohl Roundup standardmäßig Mercurial verwendet, gibt es eine Git-Klon auf GitHub. Roundup verfügt auch über verfügbare CI-Tests auf Travis CI und Codecov.
• „Es ist keine REST-API verfügbar. Es gibt ein offenes Issue in Roundup zur Hinzufügung einer REST-API. Die letzte Aktivität fand 2016 statt.“
  • Die REST-API wurde integriert und ist nun in Roundup verfügbar.
• „Benutzer-E-Mail-Adressen werden angezeigt. Es gibt keine Option, sie zu maskieren.“
  • Das Anzeigen von Adressen für registrierte und angemeldete Benutzer war eine Entscheidung, die bei der Einrichtung unserer Instanz getroffen wurde.

    Dies wurde nun geändert, sodass die E-Mail-Adressen auch für normale Benutzer verborgen sind (Entwickler und Koordinatoren können sie weiterhin sehen). Die Spalte „E-Mail-Adresse“ auf der Benutzerliste wurde ebenfalls entfernt.

• „Es werden eine Reihe unnötiger E-Mails und Benachrichtigungen gesendet, und es ist schwierig, wenn nicht unmöglich, sie zu konfigurieren.“
  • Dies kann konfiguriert werden.
• „Das Erstellen eines Kontos war mühsam. Es gab Berichte über Personen, die Probleme beim Erstellen von Konten oder beim Anmelden hatten.“
  • Das Hauptproblem sind Bestätigungs-E-Mails, die als Spam markiert werden. Es wurden Arbeiten unternommen, um das Problem zu lösen.

Überlegungen zur Migration

Dieser Abschnitt beschreibt Probleme mit den Migrationen, die möglicherweise nicht von PEP 581 und PEP 588 behandelt wurden.

PEP 588 schlägt vor, eine Schaltfläche hinzuzufügen, um Issues nur dann zu GitHub zu migrieren, wenn jemand daran weiterarbeiten möchte. Dieser Ansatz hat mehrere Probleme, aber es gibt auch andere Probleme, die unabhängig vom verwendeten Ansatz angegangen werden müssen.

• Vendor Lock-in. GitHub ist proprietär und es besteht die Gefahr von Vendor Lock-in. Ihr Geschäftsmodell könnte sich ändern und sie könnten sich ganz zurückziehen. Beispielsweise beschlossen mehrere Projekte, sich nach der Übernahme durch Microsoft von GitHub zu distanzieren.

  Wenn das Repository nicht mehr auf GitHub verfügbar ist, werden wir gezwungen sein, erneut zu migrieren, und alle Links zu den Issues funktionieren dann nicht mehr.

• Erforderliche BPO-Updates. BPO muss aktualisiert werden, um eine Schaltfläche hinzuzufügen, die nach dem Drücken ein neues Issue auf GitHub erstellt, alle Nachrichten und Anhänge kopiert und Labels für die vorhandenen Felder erstellt/hinzufügt. Die Berechtigungen müssen ebenfalls angepasst werden, um einzelne Issues nach der Migration schreibgeschützt zu machen und Benutzern die Erstellung neuer Konten zu verbieten. Möglicherweise müssen Weiterleitungen eingerichtet werden (siehe unten).
• Zwei Tracker. Wenn Issues nach Bedarf migriert werden, werden die Issues auf zwei Tracker aufgeteilt. Das Referenzieren und Suchen von Issues wird deutlich mehr Aufwand erfordern.
• Verlustbehaftete Konvertierung. Der einzige Mechanismus von GitHub zur Hinzufügung benutzerdefinierter Metadaten sind Labels. BPO verwendet eine Reihe von Feldern, um verschiedene Metadaten anzugeben. Die Beibehaltung aller Felder und Werte würde zu vielen Labels führen. Wenn nur einige Felder und Werte beibehalten werden, gehen die anderen verloren (es sei denn, es gibt eine Möglichkeit, sie woanders zu erhalten).
• Beibehaltung von Issue-IDs. GitHub bietet keine Möglichkeit, die ID migrierter Issues festzulegen und beizubehalten. Einige Projekte konnten die IDs beibehalten, indem sie den GitHub-Support kontaktierten und die Issues *en masse* migrierten. Dies ist jedoch nicht mehr möglich, da PRs und Issues denselben Namespace teilen und PRs bereits vorhandene BPO-Issue-IDs verwenden.
• Beibehaltung interner Issue-Links. Bestehende Issues können Verweise auf andere Issues in Nachrichten und Feldern enthalten (z. B. Abhängigkeiten oder Nachfolger). Da sich die Issue-ID während der Migration ändert, müssen diese aktualisiert werden. Wenn die Issues nach Bedarf migriert werden, müssen alle vorhandenen internen Verweise auf die migrierten Issues (sowohl auf BPO- als auch auf GitHub-Issues) aktualisiert werden.

  Das Einrichten einer Weiterleitung für jedes migrierte Issue auf BPO kann das Problem abmildern. Wenn jedoch die Verweise in migrierten Nachrichten nicht aktualisiert werden, führt dies zu Verwirrung (z. B. wenn BPO-Issue #1234 zu GitHub-Issue #4321 wird, könnte ein Verweis auf #1234 auf BPO-Issue #1234 verlinken und BPO kann auf GitHub-Issue #4321 weiterleiten, aber neue Verweise auf #1234 verlinken auf GitHub-PR #1234 statt auf GitHub-Issue #4321). Das manuelle Hinzufügen eines bpo- oder gh- Präfixes ist fehleranfällig.

• Beibehaltung externer Issue-Links. Eine Reihe von Websites, E-Mails usw. verlinken auf BPO-Issues. Wenn BPO abgeschaltet wird, brechen diese Links. Wenn wir die Links nicht brechen wollen, müssen wir BPO am Laufen halten und ein Weiterleitungssystem einrichten, das auf das entsprechende GitHub-Issue verlinkt.

  Darüber hinaus können wir, wenn GitHub abgeschaltet wird, keine Weiterleitungen einrichten und externe Links zu GitHub-Issues beibehalten.

• Beibehaltung und Aktualisierung von Referenzen. Zusätzlich zu Issue-Referenzen konvertiert BPO eine Reihe anderer Referenzen in Links, einschließlich Nachrichten- und PR-IDs, Changeset-Nummern, älteren SVN-Revisionsnummern, Pfaden zu Dateien im Repository, Dateien in Tracebacks (Erkennung des richtigen Branches) und Links zu Devguide-Seiten und -Abschnitten.

  Da Roundup Referenzen beim Anfordern von Nachrichten in Links umwandelt, ist es möglich, das Ziel zu aktualisieren und den richtigen Link zu generieren. Diese Notwendigkeit ergab sich bereits mehrfach, z. B.: Dateien und HG-Changesets wurden von hg.python.org zu GitHub verschoben und der Devguide wurde von docs.python.org/devguide zu devguide.python.org verschoben.

  Da Nachrichten auf GitHub statisch sind, müssen die Links während der Migration generiert und hartkodiert werden, sonst gehen sie verloren. Um sie zu aktualisieren, muss ein Werkzeug geschrieben werden, das alle Referenzen findet und die Links neu generiert.

• Wartung von Roundup und BPO. Zusätzlich zu den oben genannten Änderungen an BPO und der Entwicklung von Tools, die für die Migration zu GitHub Issues erforderlich sind, müssen wir Roundup weiterhin betreiben und warten, sowohl für unsere BPO-Instanz (schreibgeschützt) als auch für die Jython- und Roundup-Tracker (lesend/schreibend).

  Selbst wenn wir schließlich alle BPO-Issues nach GitHub migrieren und Jython und Roundup nicht mehr warten, muss BPO gewartet und auf die entsprechenden GitHub-Issues weitergeleitet werden.

• Wartung von Bots. Da GitHub nicht direkt angepasst werden kann, ist es auch notwendig, Bots zu schreiben, zu warten und zu hosten. Selbst wenn wir Roundup irgendwann nicht mehr warten, verlagert sich die Wartelast von Roundup auf die Bots. Das Hosten jedes einzelnen Bots hat auch monetäre Kosten.
• Verwendung von Issue-Vorlagen. Das manuelle Bearbeiten von Issue-Vorlagen, um „Texte zu entfernen, die für das [das] Issue nicht relevant sind“, ist umständlich und fehleranfällig.
• Signal-zu-Rausch-Verhältnis. Der Wechsel zu GitHub Issues wird wahrscheinlich die Anzahl ungültiger Berichte erhöhen und den Triage-Aufwand erhöhen. Diese Bedenken wurden bereits früher in einem Zulip-Thema geäußert.

  Es gab bereits Fälle, in denen Personen Kommentare zu PRs gepostet haben, die Moderatoren dazu veranlassten, diese als themenfremd oder störend zu markieren, sie komplett zu löschen und sogar die Konversation zu sperren (z. B. dieser PR.

• Wöchentliche Tracker-Berichte und Statistiken. Roundup sendet wöchentliche Berichte an python-dev mit einer Zusammenfassung, die neue Issues, kürzlich nicht beantwortete Issues, kürzlich zur Überprüfung anstehende Issues, am meisten diskutierte Issues, geschlossene Issues und Deltas für offene/geschlossene/Gesamt-Issue-Zählungen enthält (siehe z. B. diese Zusammenfassung). Der Bericht bietet eine einfache Möglichkeit, die Aktivität des Trackers zu verfolgen und sicherzustellen, dass Issues, die Aufmerksamkeit erfordern, bemerkt werden.

  Die im Wochenbericht gesammelten Daten werden auch verwendet, um Statistiken und Grafiken zu generieren, die verwendet werden können, um neue Erkenntnisse zu gewinnen.

• BPO-bezogene MLs. Es gibt derzeit zwei Mailinglisten, auf denen BPO neue Tracker-Issues und alle Nachrichten postet: new-bugs-announce und python-bugs-list. Ein neues System muss entwickelt werden, um diese Funktionalität beizubehalten. Diese MLs bieten zusätzliche Möglichkeiten, die Tracker-Aktivität zu verfolgen.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.