22.11.2 Umgang mit Patches und Branches

Ä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 angeben⁴⁵. 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.