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 anlegen, zunächst eine Meldung als „Fehlerbericht“ an guix-patches zu schicken (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

The QA infrastructure recognizes such issues and lists the merge requests on its main page. The following points apply to managing these branches:

1. The commits on the branch should be a combination of the patches relevant to the branch. Patches not related to the topic of the branch should go elsewhere.
2. Any changes that can be made on the master branch, should be made on the master branch. If a commit can be split to apply part of the changes on master, this is good to do.
3. It should be possible to re-create the branch by starting from master and applying the relevant patches.
4. Avoid merging master in to the branch. Prefer rebasing or re-creating the branch on top of an updated master revision.
5. Minimise the changes on master that are missing on the branch prior to merging the branch in to master. This means that the state of the branch better reflects the state of master should the branch be merged.
6. If you don’t have commit access, create the “Request for merging” issue and request that someone creates the branch. Include a list of issues/patches to include on the branch.

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.

Once the branch has been merged, the issue should be closed and the branch deleted.

Sometimes, a branch may be a work in progress, for example for larger efforts such as updating the GNOME desktop. In these cases, the branch name should reflect this by having the ‘wip-’ prefix. The QA infrastructure will avoid building work-in-progress branches, so that the available resources can be better focused on building the branches that are ready to be merged. When the branch is no longer a work in progress, it should be renamed, with the ‘wip-’ prefix removed, and only then should the merge requests be created, as documented earlier.