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.

To help coordinate the merging of branches, you must create a new guix-patches issue each time you wish to merge a branch (siehe Der Issue-Tracker). The title of the issue requesting to merge a branch should have the following format:

Request for merging "name" branch

The QA infrastructure recognizes such issues and lists the merge requests on its main page. Normally branches will be merged in a “first come, first merged” manner, tracked through the guix-patches issues.

If you agree on a different order with those involved, you can track this by updating which issues block⁴⁵ which other issues. Therefore, to know which branch is at the front of the queue, look for the oldest issue, or the issue that isn’t blocked by any other branch merges. An ordered list of branches with the open issues is available at https://qa.guix.gnu.org.

Once a branch is at the front of the queue, wait until sufficient time has passed for the build farms to have processed the changes, and for the necessary testing to have happened. For example, you can check ‘https://qa.guix.gnu.org/branch/branch’ to see information on some builds and substitute availability.