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 create 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. 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.

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.

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.