Nächste: Beiträge von anderen überprüfen, Vorige: Überblick über gemeldete Fehler und Änderungen, Nach oben: Mitwirken [Inhalt][Index]
Jeder kann bei Guix mitmachen, auch ohne Commit-Zugriff zu haben (siehe Einreichen von Patches). Für Leute, die häufig zu Guix beitragen, kann es jedoch praktischer sein, Schreibzugriff auf das Repository zu haben. Als Daumenregel sollte ein Mitwirkender 50-mal überprüfte Commits eingebracht haben, um als Committer zu gelten, und schon mindestens 6 Monate im Projekt aktiv sein. Dadurch gab es genug Zusammenarbeit, um Mitwirkende einzuarbeiten und einzuschätzen, ob sie so weit sind, Committer zu werden. Dieser Commit-Zugriff sollte nicht als Auszeichnung verstanden werden, sondern als Verantwortung, die ein Mitwirkender auf sich nimmt, um dem Projekt zu helfen. Von allen Mitwirkenden wird erwartet, und erst recht von Committern, zu einer Konsensbildung beizutragen und Entscheidungen mit Konsens zu treffen. Weil wir Konsens wollen, haben wir das Ziel, Lösungen zu finden, mit denen jeder leben kann. Es bedeutet, dass wir keine Entscheidung gegen größere Bedenken fällen und wir solche Bedenken aktiv mit Vorschlägen angehen, die alle gut finden. Wenn ein Mitwirkender (mit oder ohne Commit-Zugriff) sich gegen einen Vorschlag sperren möchte, geht auch damit besondere Verantwortung einher, andere Möglichkeiten zu finden und Ideen oder Code einzubringen bzw. den Grund darzulegen, weshalb es so bleiben sollte, wie es ist. Vorschläge sollen nicht stecken bleiben. Wir ermutigen Sie dazu, https://www.seedsforchange.org.uk/consensus zu lesen, um ein Verständnis für Konsensentscheidungen zu entwickeln und Einzelheiten zu meistern.
Im folgenden Abschnitt wird beschrieben, wie jemand Commit-Zugriff bekommt, was man tun muss, bevor man zum ersten Mal einen Commit pusht, und welche Richtlinien und Erwartungen die Gemeinschaft an Commits richtet, die auf das offizielle Repository gepusht werden.
Wenn Sie es für angemessen halten, dann sollten Sie in Erwägung ziehen, sich wie folgt um Commit-Zugriff zu bewerben:
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.
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
Wichtig: Bevor Sie zum ersten Mal pushen dürfen, müssen die Betreuer:
- Ihren OpenPGP-Schlüssel zum
keyring-Branch hinzugefügt haben,- Ihren OpenPGP-Fingerabdruck in die Datei .guix-authorizations derjenigen Branches eingetragen haben, auf die Sie commiten möchten.
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:
make authenticate
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.
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).
Ensure you’re aware of how the changes should be handled (siehe Umgang mit Patches und Branches) prior to being pushed to the repository, especially
for the master branch.
Wenn es Ihre eigenen Änderungen sind, die Sie commiten und pushen, lassen Sie mindestens eine Woche Zeit, damit andere Ihre Änderungen begutachten können (zwei Wochen bei nennenswerten Änderungen), nachdem Sie sie zum Überprüfen eingeschickt haben. Wenn danach niemand anders die Zeit zum Prüfen findet und Sie von den Änderungen überzeugt sind, ist es in Ordnung, sie zu commiten.
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
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.
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.
Betreuer48 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:
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.
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!
Siehe https://guix.gnu.org/en/about für eine Liste der Betreuer. Sie können ihnen eine private E-Mail schicken an guix-maintainers@gnu.org.
Nächste: Beiträge von anderen überprüfen, Vorige: Überblick über gemeldete Fehler und Änderungen, Nach oben: Mitwirken [Inhalt][Index]