22.14.1 Um Commit-Zugriff bewerben

Wenn Sie es für angemessen halten, dann sollten Sie in Erwägung ziehen, sich wie folgt um Commit-Zugriff zu bewerben:

1. Finden Sie drei Committer, die für Sie eintreten. Sie können die Liste der Committer unter https://savannah.gnu.org/project/memberlist.php?group=guix finden. Jeder von ihnen sollte eine entsprechende Erklärung per E-Mail an guix-maintainers@gnu.org schicken (eine private Alias-Adresse für das Kollektiv aus allen Betreuern bzw. Maintainern), die jeweils mit ihrem OpenPGP-Schlüssel signiert wurde.

   Von den Committern wird erwartet, dass sie bereits mit Ihnen als Mitwirkendem zu tun hatten und beurteilen können, ob Sie mit den Richtlinien des Projekts hinreichend vertraut sind. Dabei geht es nicht darum, wie wertvoll Ihre Beiträge sind, daher sollte eine Ablehnung mehr als „schauen wir später nochmal“ verstanden werden.

2. Senden Sie eine Nachricht an guix-maintainers@gnu.org, in der Sie Ihre Bereitschaft darlegen und die Namen der drei Committer nennen, die Ihre Bewerbung unterstützen. Die Nachricht sollte mit dem OpenPGP-Schlüssel signiert sein, mit dem Sie später auch Ihre Commits signieren, und Sie sollten den Fingerabdruck hinterlegen (siehe unten). Siehe https://emailselfdefense.fsf.org/de/ für eine Einführung in asymmetrische Kryptografie („Public-Key“) mit GnuPG.

   Richten Sie GnuPG so ein, dass es niemals den SHA1-Hashalgorithmus für digitale Signaturen verwendet, der seit 2019 bekanntlich unsicher ist. Fügen Sie dazu zum Beispiel folgende Zeile in ~/.gnupg/gpg.conf ein (siehe GPG Esoteric Options in The GNU Privacy Guard Manual):

   digest-algo sha512
   

3. Betreuer entscheiden letztendlich darüber, ob Ihnen Commit-Zugriff gegeben wird, folgen dabei aber normalerweise der Empfehlung Ihrer Fürsprecher.
4. Wenn und sobald Ihnen Zugriff gewährt wurde, senden Sie bitte eine Nachricht an guix-devel@gnu.org, um dies bekanntzugeben, die Sie erneut mit dem OpenPGP-Schlüssel signiert haben, mit dem Sie Commits signieren (tun Sie das, bevor Sie Ihren ersten Commit pushen). Auf diese Weise kann jeder Ihren Beitritt mitbekommen und nachprüfen, dass dieser OpenPGP-Schlüssel wirklich Ihnen gehört.

   Wichtig: Bevor Sie zum ersten Mal pushen dürfen, müssen die Betreuer:

   1. Ihren OpenPGP-Schlüssel zum keyring-Branch hinzugefügt haben,
   2. Ihren OpenPGP-Fingerabdruck in die Datei .guix-authorizations derjenigen Branches eingetragen haben, auf die Sie commiten möchten.

5. Wenn Sie den Rest dieses Abschnitts jetzt auch noch lesen, steht Ihrer Karriere nichts mehr im Weg!

Anmerkung: Betreuer geben gerne anderen Leuten Commit-Zugriff, die schon einige Zeit dabei waren und ihre Eignung unter Beweis gestellt haben. Seien Sie nicht schüchtern und unterschätzen Sie Ihre Arbeit nicht!

Sie sollten sich bewusst sein, dass unser Projekt auf ein besser automatisiertes System hinarbeitet, um Patches zu überprüfen und zu mergen. Als Folge davon werden wir vielleicht weniger Leuten Commit-Zugriff auf das Haupt-Repository geben. Bleiben Sie auf dem Laufenden!

Alle Commits, die auf das zentrale Repository auf Savannah gepusht werden, müssen mit einem OpenPGP-Schlüssel signiert worden sein, und diesen öffentlichen Schlüssel sollten Sie auf Ihr Benutzerkonto auf Savannah und auf öffentliche Schlüsselserver wie keys.openpgp.org hochladen. Um Git so zu konfigurieren, dass es Commits automatisch signiert, führen Sie diese Befehle aus:

git config commit.gpgsign true

# Ersetzen Sie den Fingerabdruck durch Ihren öffentlichen PGP-Schlüssel.
git config user.signingkey CABBA6EA1DC0FF33

Um zu prüfen, ob Commits mit dem richtigen Schlüssel signiert wurden, benutzen Sie:

guix git authenticate

Siehe Erstellung aus dem Git, wie man zum ersten Mal ein Guix-Checkout authentifiziert.

Als Vorsichtsmaßnahme, um nicht versehentlich unsignierte oder mit dem falschen Schlüssel signierte Commits auf Savannah zu pushen, sollten Sie Git so eingerichtet haben, wie es in Git einrichten vorgeschrieben ist.

22.14.2 Commit-Richtlinie

Wenn Sie Commit-Zugriff erhalten, passen Sie bitte auf, dass Sie der folgenden Richtlinie folgen (Diskussionen über die Richtlinie können wir auf guix-devel@gnu.org führen).

Das Verfahren, das Änderungsvorschläge durchlaufen (siehe Umgang mit Patches und Branches), muss Ihnen bekannt sein, wenn es um Pushs auf das Repository geht, gerade beim master-Branch.

If you’re committing and pushing your own changes, try and wait at least one week (two weeks for more significant changes, up to one month for changes such as removing a package—siehe Package Removal) after you send them for review. After this, if no one else is available to review them and if you’re confident about the changes, it’s OK to commit.

Wenn Sie einen Commit für jemand anderen pushen, fügen Sie bitte eine Signed-off-by-Zeile am Ende der Commit-Log-Nachricht hinzu – z.B. mit git am --signoff. Dadurch lässt es sich leichter überblicken, wer was getan hat.

Wenn Sie Kanalneuigkeiten hinzufügen (siehe Kanalneuigkeiten verfassen), dann sollten Sie prüfen, dass diese wohlgeformt sind, indem Sie den folgenden Befehl direkt vor dem Pushen ausführen:

make check-channel-news

22.14.3 Mit Fehlern umgehen

Durch Begutachten der von anderen eingereichten Patches („Peer-Review“, siehe Einreichen von Patches) und durch Werkzeuge wie guix lint (siehe guix lint aufrufen) und den Testkatalog (siehe Den Testkatalog laufen lassen) sollten Sie Fehler finden können, ehe sie gepusht wurden. Trotz allem kann es gelegentlich vorkommen, dass nicht bemerkt wird, wenn nach einem Commit etwas in Guix nicht mehr funktioniert. Wenn das passiert, haben zwei Dinge Vorrang: Schadensbegrenzung und Verstehen, was passiert ist, damit es nicht wieder zu vergleichbaren Fehlern kommt. Die Verantwortung dafür tragen in erster Linie die Beteiligten, aber wie bei allem anderen handelt es sich um eine Aufgabe der Gruppe.

Manche Fehler können sofort alle Nutzer betreffen, etwa wenn guix pull dadurch nicht mehr funktioniert oder Kernfunktionen von Guix ausfallen, wenn wichtige Pakete nicht mehr funktionieren (zur Erstellungs- oder zur Laufzeit) oder wenn bekannte Sicherheitslücken eingeführt werden.

Die am Verfassen, Begutachten und Pushen von Commits Beteiligten sollten zu den ersten gehören, die für zeitnahe Schadensbegrenzung sorgen, indem sie mit einem nachfolgenden Commit („Follow-up“) den Fehler falls möglich beseitigen oder den vorherigen Commit rückgängig machen („Revert“), damit Zeit ist, das Problem auf ordentliche Weise zu beheben. Auch sollten sie das Problem mit anderen Entwicklern bereden.

Wenn diese Personen nicht verfügbar sind, um den Fehler zeitnah zu beheben, steht es anderen Committern zu, deren Commit(s) zu reverten und im Commit-Log und auf der Mailingliste zu erklären, was das Problem war. Ziel ist, dem oder den ursprünglichen Committer(n), Begutachter(n) und Autoren mit mehr Zeit Gelegenheit zu geben, einen Vorschlag zum weiteren Vorgehen zu machen.

Wenn das Problem erledigt wurde, müssen die Beteiligten ein Verständnis für die Situation sicherstellen. Während Sie sich um Verständnis bemühen, legen Sie den Fokus auf das Sammeln von Informationen und vermeiden Sie Schuldzuweisungen. Lassen Sie die Beteiligten beschreiben, was passiert ist, aber bitten Sie sie nicht, die Situation zu erklären, weil ihnen das implizit Schuld zuspricht, was nicht hilfreich ist. Verantwortung ergibt sich aus Einigkeit über das Problem, dass man daraus lernt und die Prozesse verbessert, damit es nicht wieder vorkommt.

22.14.4 Entzug des Commit-Zugriffs

Damit es weniger wahrscheinlich ist, dass Fehler passieren, werden wir das Savannah-Konto von Committern nach 12 Monaten der Inaktivität aus dem Guix-Projekt bei Savannah löschen und ihren Schlüssel aus .guix-authorizations entfernen. Solche Committer können den Betreuern eine E-Mail schicken, um ohne einen Durchlauf des Fürsprecherprozesses wieder Commit-Zugriff zu bekommen.

Betreuer⁵⁰ dürfen als letzten Ausweg auch jemandem die Commit-Berechtigung entziehen, wenn die Zusammenarbeit mit der übrigen Gemeinde zu viel Reibung erzeugt hat – selbst wenn sich alles im Rahmen der Verhaltensregeln abgespielt hat (siehe Mitwirken). Davon machen Betreuer nur Gebrauch nach öffentlichen oder privaten Diskussionen mit der betroffenen Person und nach eindeutiger Ankündigung. Beispiele für Verhalten, das die Zusammenarbeit behindert und zu so einer Entscheidung führen könnte, sind:

• wiederholte Verletzung der oben beschriebenen Commit-Richtlinie,
• wiederholtes Ignorieren von Kritik anderer Entwickler,
• verletztes Vertrauen durch mehrere schwere Vorkommnisse in Folge.

Wenn Betreuer diesen Entschluss treffen, benachrichtigen sie die Entwickler auf guix-devel@gnu.org; Anfragen können an guix-maintainers@gnu.org gesendet werden. Abhängig von der Situation wird ein Mitwirken der Betroffenen trotzdem weiterhin gerne gesehen.

22.14.5 Aushelfen

Eine Sache noch: Das Projekt entwickelt sich nicht nur deswegen schnell, weil Committer ihre eigenen tollen Änderungen pushen, sondern auch, weil sie sich Zeit nehmen, die Änderungen anderer Leute in „Reviews“ zu überprüfen und zu pushen. Wir begrüßen es, wenn Sie als Committer Ihre Expertise und Commit-Rechte dafür einsetzen, auch anderen Mitwirkenden zu helfen!