Nächste: Debbugs-Benutzerschnittstellen, Vorige: Der Issue-Tracker, Nach oben: Überblick über gemeldete Fehler und Änderungen [Inhalt][Index]
Änderungen sollten an guix-patches@gnu.org geschickt werden. Was an
diese Mailing-Liste geschickt wird, steht danach in der Patch-Datenbank
(siehe Der Issue-Tracker). Auch springen daraufhin weitere Werkzeuge
zur Qualitätssicherung an; sobald diese die Änderung überprüft haben, wird
auf ‘https://qa.guix.gnu.org/issue/FEHLERNUMMER
’ das
Ergebnis präsentiert; dabei ist mit FEHLERNUMMER die Zahl gemeint, die
vom Issue-Tracker zugewiesen wurde. Warten Sie ab, bis ein Mensch die
Änderung überprüft hat, ohne etwas zu commiten.
Eine Ausnahme machen wir bei „trivialen“ oder „offensichtlichen“
Änderungen. Diese darf man direkt auf den master
-Branch pushen. Zu
den trivialen Änderungen gehört zum Beispiel das Beheben von Schreibfehlern
oder unmittelbar problematische Änderungen rückgängig zu machen. Die letzten
Anweisungen werden wir vielleicht noch ändern, damit man unstrittige
Änderungen direkt commiten kann, wenn man mit von Änderungen betroffenen
Teilen vertraut ist.
Änderungen, die mehr als 300 abhängige Pakete beeinflussen (siehe
guix refresh
aufrufen), sollten erst mal auf einen themenbezogenen
„Topic Branch“ statt auf master
gepusht werden. Die Änderungen auf
einem Branch sollten zusammenpassen, z.B. eine Aktualisierung von GNOME,
von NumPy oder Ähnliches. So können die Änderungen getestet werden: Der
Branch ist nach einiger Zeit auf
‘https://qa.guix.gnu.org/branch/Branch
’ zu finden, wo
angezeigt wird, welchen Status die Erstellungen auf verschiedenen
Plattformen haben.
Um das Mergen von Branches besser zu koordinieren, ist es Ihre Pflicht, jedes Mal, wenn Sie einen Branch mergen möchten, zunächst eine Meldung als „Fehlerbericht“ an guix-patches zu schicken (einen „Merge Request“), siehe Der Issue-Tracker. Als Titel der Meldung, mit der Sie um die Mergeerlaubnis bitten, verwenden Sie etwas im folgenden Format:
Request for merging "Name" branch
Durch die QA-Infrastruktur (Quality Assurance, englisch für Qualitätssicherung) erkennt solche Meldungen und listet Merge Requests auf seiner Hauptseite auf. Normalerweise verfährt man nach dem Prinzip: „Was zuerst kommt, merget man zuerst.“ Den Fortschritt kann man über den Fehlerbericht bei guix-patches nachvollziehen.
Wenn Sie eine andere Reihenfolge mit den Beteiligten absprechen, können Sie dies zur Nachvollziehbarkeit über die diesen Fehlerbericht blockierenden Fehlerberichte angeben45. Darum können Sie den Branch, der zuerst an der Reihe ist, finden, indem Sie den ältesten Fehlerbericht suchen, der von keinem anderen Branch-Merge blockiert wird. Die Liste der Branches in sortierter Reihenfolge mit den offenen Fehlerberichten können Sie von https://qa.guix.gnu.org abrufen.
Sobald ein Branch in der Reihenfolge vorne steht, warten Sie darauf, dass
genügend Zeit verstrichen ist, damit die Erstellungfarm die Änderungen
verarbeitet hat und die notwendige Überprüfung stattfinden konnte. Sie
können zum Beispiel auf
‘https://qa.guix.gnu.org/branch/Branch
’ Informationen zu
neuen Erstellungen und zur Substitutverfügbarkeit sehen.
Sie können markieren, dass ein Fehlerbericht
von einem anderen blockiert wird, indem Sie eine E-Mail an
control@debbugs.gnu.org schicken, die folgende Zeile enthält:
block XXXXX by YYYYY
. Dabei schreiben Sie statt XXXXX
die
Fehlernummer des blockierten Fehlerberichts und statt YYYYY
die
Fehlernummer des blockierenden Fehlerberichts.
Nächste: Debbugs-Benutzerschnittstellen, Vorige: Der Issue-Tracker, Nach oben: Überblick über gemeldete Fehler und Änderungen [Inhalt][Index]