@node Mitwirken @chapter Mitwirken Dieses Projekt basiert auf Kooperation, daher benötigen wir Ihre Hilfe, um es wachsen zu lassen! Bitte kontaktieren Sie uns auf @email{guix-devel@@gnu.org} und @code{#guix} im Freenode-IRC-Netzwerk. Wir freuen uns auf Ihre Ideen, Fehlerberichte, Patches und alles, was hilfreich für das Projekt sein könnte. Besonders willkommen ist Hilfe bei der Erstellung von Paketen (@pxref{Paketrichtlinien}). @cindex Verhaltensregeln, für Mitwirkende @cindex Verhaltenskodex für Mitwirkende Wir möchten eine angenehme, freundliche und von Belästigungen freie Umgebung bereitstellen, so dass jeder Beiträge nach seinen Fähigkeiten leisten kann. Zu diesem Zweck verwendet unser Projekt einen »Verhaltenskodex für Mitwirkende«, der von @url{http://contributor-covenant.org/} übernommen wurde. Eine übersetzte Fassung finden Sie auf @url{https://www.contributor-covenant.org/de/version/1/4/code-of-conduct} sowie eine mitgelieferte, englische Fassung in der Datei @file{CODE-OF-CONDUCT} im Quellbaum. Von Mitwirkenden wird nicht erwartet, dass sie in Patches oder in der Online-Kommunikation ihre echten Namen preisgeben. Sie können einen beliebigen Namen oder ein Pseudonym ihrer Wahl verwenden. @menu * Erstellung aus dem Git:: Das Neueste und Beste. * Guix vor der Installation ausführen:: Hacker-Tricks. * Perfekt eingerichtet:: Die richtigen Werkzeuge. * Code-Stil:: Wie Mitwirkende hygienisch arbeiten. * Einreichen von Patches:: Teilen Sie Ihre Arbeit. @end menu @node Erstellung aus dem Git @section Erstellung aus dem Git Wenn Sie an Guix selbst hacken wollen, ist es empfehlenswert, dass Sie die neueste Version aus dem Git-Softwarebestand verwenden: @example git clone https://git.savannah.gnu.org/git/guix.git @end example Wenn Sie Guix aus einem Checkout erstellen, sind außer den bereits in den Installationsanweisungen genannten Paketen weitere nötig (@pxref{Voraussetzungen}). @itemize @item @url{http://gnu.org/software/autoconf/, GNU Autoconf}; @item @url{http://gnu.org/software/automake/, GNU Automake}; @item @url{http://gnu.org/software/gettext/, GNU Gettext}; @item @url{http://gnu.org/software/texinfo/, GNU Texinfo}; @item @url{http://www.graphviz.org/, Graphviz}; @item @url{http://www.gnu.org/software/help2man/, GNU Help2man (optional)}. @end itemize Der einfachste Weg, eine Entwicklungsumgebung für Guix einzurichten, ist natürlich, Guix zu benutzen! Der folgende Befehl startet eine neue Shell, in der alle Abhängigkeiten und Umgebungsvariablen bereits eingerichtet sind, um an Guix zu arbeiten: @example guix environment guix @end example In @xref{Aufruf von guix environment} finden Sie weitere Informationen zu diesem Befehl. Zusätzliche Abhängigkeiten können mit @option{--ad-hoc} hinzugefügt werden: @example guix environment guix --ad-hoc help2man git strace @end example Führen Sie @command{./bootstrap} aus, um die Infrastruktur des Erstellungssystems mit Autoconf und Automake zu erstellen. Möglicherweise erhalten Sie eine Fehlermeldung wie diese: @example configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES @end example @noindent Das bedeutet wahrscheinlich, dass Autoconf @file{pkg.m4} nicht finden konnte, welches von pkg-config bereitgestellt wird. Stellen Sie sicher, dass @file{pkg.m4} verfügbar ist. Gleiches gilt für den von Guile bereitgestellten Makrosatz @file{guile.m4}. Wenn Sie beispielsweise Automake in @file{/usr/local} installiert haben, würde in @file{/usr/share} nicht nach @file{.m4}-Dateien geschaut. In einem solchen Fall müssen Sie folgenden Befehl aufrufen: @example export ACLOCAL_PATH=/usr/share/aclocal @end example In @xref{Macro Search Path,,, automake, The GNU Automake Manual} finden Sie weitere Informationen. Dann führen Sie wie gewohnt @command{./configure} aus. Achten Sie darauf, @code{--localstatedir=@var{Verzeichnis}} zu übergeben, wobei @var{Verzeichnis} der von Ihrer aktuellen Installation verwendete @code{localstatedir}-Wert ist (weitere Informationen auf @pxref{Der Store}). Zum Schluss müssen Sie @code{make check} aufrufen, um die Tests auszuführen (@pxref{Die Testsuite laufen lassen}). Falls etwas fehlschlägt, werfen Sie einen Blick auf die Installationsanweisungen (@pxref{Installation}) oder senden Sie eine E-Mail an die @email{guix-devel@@gnu.org, Mailingliste}. @node Guix vor der Installation ausführen @section Guix vor der Installation ausführen Um eine gesunde Arbeitsumgebung zu erhalten, ist es hilfreich, die im lokalen Quellbaum vorgenommenen Änderungen zunächst zu testen, ohne sie tatsächlich zu installieren. So können Sie zwischen Ihrem Endnutzer-»Straßenanzug« und Ihrem »Faschingskostüm« unterscheiden. To that end, all the command-line tools can be used even if you have not run @code{make install}. To do that, you first need to have an environment with all the dependencies available (@pxref{Erstellung aus dem Git}), and then simply prefix each command with @command{./pre-inst-env} (the @file{pre-inst-env} script lives in the top build tree of Guix; it is generated by @command{./configure}), as in@footnote{The @option{-E} flag to @command{sudo} guarantees that @code{GUILE_LOAD_PATH} is correctly set such that @command{guix-daemon} and the tools it uses can find the Guile modules they need.}: @example $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild $ ./pre-inst-env guix build hello @end example @noindent Entsprechend, um eine Guile-Sitzung zu öffnen, die die Guix-Module benutzt: @example $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))' ;;; ("x86_64-linux") @end example @noindent @cindex REPL @cindex Lese-Auswerten-Schreiben-Schleife @dots{} und auf einer REPL (@pxref{Using Guile Interactively,,, guile, Guile Reference Manual}): @example $ ./pre-inst-env guile scheme@@(guile-user)> ,use(guix) scheme@@(guile-user)> ,use(gnu) scheme@@(guile-user)> (define snakes (fold-packages (lambda (package lst) (if (string-prefix? "python" (package-name package)) (cons package lst) lst)) '())) scheme@@(guile-user)> (length snakes) $1 = 361 @end example Das @command{pre-inst-env}-Skript richtet alle Umgebungsvariablen ein, die nötig sind, um dies zu ermöglichen, einschließlich @env{PATH} und @env{GUILE_LOAD_PATH}. Note that @command{./pre-inst-env guix pull} does @emph{not} upgrade the local source tree; it simply updates the @file{~/.config/guix/current} symlink (@pxref{Aufruf von guix pull}). Run @command{git pull} instead if you want to upgrade your local source tree. @node Perfekt eingerichtet @section Perfekt eingerichtet Um perfekt für das Hacken an Guix eingerichtet zu sein, brauchen Sie an sich dasselbe wie um perfekt für das Hacken mit Guile (@pxref{Using Guile in Emacs,,, guile, Guile Reference Manual}). Zunächst brauchen Sie mehr als ein Textverarbeitungsprogramm, Sie brauchen @url{http://www.gnu.org/software/emacs, Emacs}, ermächtigt vom wunderbaren @url{http://nongnu.org/geiser/, Geiser}. Geiser ermöglicht interaktive und inkrementelle Entwicklung aus Emacs heraus: Code kann in Puffern kompiliert und ausgewertet werden. Zugang zu Online-Dokumentation (Docstrings) steht ebenso zur Verfügung wie kontextabhängige Vervollständigung, @kbd{M-.} um zu einer Objektdefinition zu springen, eine REPL, um Ihren Code auszuprobieren, und mehr (@pxref{Einführung,,, geiser, Geiser User Manual}). Zur bequemen Guix-Entwicklung sollten Sie Guiles Ladepfad so ergänzen, dass die Quelldateien in Ihrem Checkout gefunden werden. @lisp ;; @r{Angenommen das Guix-Checkout ist in ~/src/guix.} (with-eval-after-load 'geiser-guile (add-to-list 'geiser-guile-load-path "~/src/guix")) @end lisp Um den Code tatsächlich zu bearbeiten, bietet Emacs schon einen netten Scheme-Modus. Aber Sie dürfen auch @url{http://www.emacswiki.org/emacs/ParEdit, Paredit} nicht verpassen. Es bietet Hilfsmittel, um direkt mit dem Syntaxbaum zu arbeiten, und kann so zum Beispiel einen S-Ausdruck hochheben oder ihn umhüllen, ihn verschlucken oder den nachfolgenden S-Ausdruck verwerfen, etc. @cindex Code-Schnipsel @cindex Vorlagen @cindex Tipparbeit sparen Wir bieten auch Vorlagen für häufige Git-Commit-Nachrichten und Paketdefinitionen im Verzeichnis @file{etc/snippets}. Diese Vorlagen können mit @url{http://joaotavora.github.io/yasnippet/, YASnippet} zusammen benutzt werden, um kurze Auslöse-Zeichenketten zu interaktiven Textschnipseln umzuschreiben. Vielleicht möchten Sie das Schnipselverzeichnis zu Ihrer @var{yas-snippet-dirs}-Variablen in Emacs hinzufügen. @lisp ;; @r{Angenommen das Guix-Checkout ist in ~/src/guix.} (with-eval-after-load 'yasnippet (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets")) @end lisp The commit message snippets depend on @url{https://magit.vc/, Magit} to display staged files. When editing a commit message type @code{add} followed by @kbd{TAB} to insert a commit message template for adding a package; type @code{update} followed by @kbd{TAB} to insert a template for updating a package; type @code{https} followed by @kbd{TAB} to insert a template for changing the home page URI of a package to HTTPS. Das Hauptschnipsel für @code{scheme-mode} wird ausgelöst, indem Sie @code{package...} gefolgt von @kbd{TAB} eintippen. Dieses Snippet fügt auch die Auslöse-Zeichenkette @code{origin...} ein, die danach weiter umgeschrieben werden kann. Das @code{origin}-Schnipsel kann wiederum andere Auslöse-Zeichenketten einfügen, die alle auf @code{...} enden, was selbst wieder weiter umgeschrieben werden kann. @node Code-Stil @section Code-Stil Im Allgemeinen folgt unser Code den GNU Coding Standards (@pxref{Top,,, standards, GNU Coding Standards}). Da diese aber nicht viel über Scheme zu sagen haben, folgen hier einige zusätzliche Regeln. @menu * Programmierparadigmen:: Wie Sie Ihre Elemente zusammenstellen. * Module:: Wo Sie Ihren Code unterbringen. * Datentypen und Mustervergleich:: Implementierung von Datenstrukturen. * Formatierung von Code:: Schreibkonventionen. @end menu @node Programmierparadigmen @subsection Programmierparadigmen Scheme-Code wird in Guix auf rein funktionale Weise geschrieben. Eine Ausnahme ist Code, der mit Ein- und Ausgabe zu tun hat, und Prozeduren, die grundlegende Konzepte implementieren, wie zum Beispiel die Prozedur @code{memoize}. @node Module @subsection Module Guile-Module, die beim Erstellen nutzbar sein sollen, müssen im Namensraum @code{(guix build @dots{})} leben. Sie dürfen auf keine anderen Guix- oder GNU-Module Bezug nehmen. Jedoch ist es in Ordnung, wenn ein »wirtsseitiges« Modul ein erstellungsseitiges Modul benutzt. Module, die mit dem weiteren GNU-System zu tun haben, sollten im Namensraum @code{(gnu @dots{})} und nicht in @code{(guix @dots{})} stehen. @node Datentypen und Mustervergleich @subsection Datentypen und Mustervergleich Im klassischen Lisp gibt es die Tendenz, Listen zur Darstellung von allem zu benutzen, und diese dann »händisch« zu durchlaufen mit @code{car}, @code{cdr}, @code{cadr} und so weiter. Dieser Stil ist aus verschiedenen Gründen problematisch, insbesondere wegen der Tatsache, dass er schwer zu lesen, schnell fehlerbehaftet und ein Hindernis beim Melden von Typfehlern ist. Guix-Code sollte angemessene Datentypen definieren (zum Beispiel mit @code{define-record-type*}) statt Listen zu missbrauchen. Außerdem sollte er das @code{(ice-9 match)}-Modul von Guile zum Mustervergleich benutzen, besonders mit Listen. @node Formatierung von Code @subsection Formatierung von Code @cindex Formatierung von Code @cindex Code-Stil Beim Schreiben von Scheme-Code halten wir uns an die üblichen Gepflogenheiten unter Scheme-Programmierern. Im Allgemeinen bedeutet das, dass wir uns an @url{http://mumble.net/~campbell/scheme/style.txt, Riastradh's Lisp Style Rules} halten. Es hat sich ergeben, dass dieses Dokument auch die Konventionen beschreibt, die im Code von Guile hauptsächlich verwendet werden. Es ist gut durchdacht und schön geschrieben, also lesen Sie es bitte. Ein paar in Guix eingeführte Sonderformen, wie zum Beispiel das @code{substitute*}-Makro, haben abweichende Regeln für die Einrückung. Diese sind in der Datei @file{.dir-locals.el} definiert, die Emacs automatisch benutzt. Beachten Sie auch, dass Emacs-Guix einen Modus namens @code{guix-devel-mode} bereitstellt, der Guix-Code richtig einrückt und hervorhebt (@pxref{Development,,, emacs-guix, The Emacs-Guix Reference Manual}). @cindex Einrückung, Code- @cindex Formatierung, Code- Falls Sie nicht Emacs verwenden, sollten Sie sicherstellen, dass Ihr Editor diese Regeln kennt. Um eine Paketdefinition automatisch einzurücken, können Sie auch Folgendes ausführen: @example ./etc/indent-code.el gnu/packages/@var{Datei}.scm @var{Paket} @end example @noindent Dadurch wird die Definition von @var{Paket} in @file{gnu/packages/@var{Datei}.scm} automatisch eingerückt, indem Emacs im Batch-Modus läuft. Um die Einrückung in einer gesamten Datei vorzunehmen, lassen Sie das zweite Argument weg: @example ./etc/indent-code.el gnu/services/@var{Datei}.scm @end example @cindex Vim, zum Editieren von Scheme-Code Wenn Sie Code mit Vim bearbeiten, empfehlen wir, dass Sie @code{:set autoindent} ausführen, damit Ihr Code automatisch eingerückt wird, während Sie ihn schreiben. Außerdem könnte Ihnen @uref{https://www.vim.org/scripts/script.php?script_id=3998, @code{paredit.vim}} dabei helfen, mit all diesen Klammern fertigzuwerden. Wir fordern von allen Prozeduren auf oberster Ebene, dass sie über einen Docstring verfügen. Diese Voraussetzung kann jedoch bei einfachen, privaten Prozeduren im Namensraum @code{(guix build @dots{})} aufgeweicht werden. Prozeduren sollten nicht mehr als vier positionsbestimmte Parameter haben. Benutzen Sie Schlüsselwort-Parameter für Prozeduren, die mehr als vier Parameter entgegennehmen. @node Einreichen von Patches @section Einreichen von Patches Die Entwicklung wird mit Hilfe des verteilten Versionskontrollsystems Git durchgeführt. Daher ist eine ständige Verbindung zum Repository nicht unbedingt erforderlich. Wir begrüßen Beiträge in Form von Patches, die mittels @code{git format-patch} erstellt und an die Mailingliste @email{guix-patches@@gnu.org} geschickt werden. Diese Mailing-Liste setzt auf einer Debbugs-Instanz auf, die zugänglich ist unter @uref{https://bugs.gnu.org/guix-patches}, wodurch wir den Überblick über Eingereichtes behalten können. Jede an diese Mailing-Liste gesendete Nachricht bekommt eine neue Folgenummer zugewiesen, so dass man eine Folge-Email zur Einreichung an @code{@var{NNN}@@debbugs.gnu.org} senden kann, wobei @var{NNN} für die Folgenummer steht (@pxref{Senden einer Patch-Reihe}). Bitte schreiben Sie Commit-Logs im ChangeLog-Format (@pxref{Change Logs,,, standards, GNU Coding Standards}); dazu finden Sie Beispiele unter den bisherigen Commits. Bevor Sie einen Patch einreichen, der eine Paketdefinition hinzufügt oder verändert, gehen Sie bitte diese Prüfliste durch: @enumerate @item Wenn die Autoren der verpackten Software eine kryptographische Signatur für den Tarball der Veröffentlichung anbieten, so machen Sie sich bitte die Mühe, die Echtheit des Archivs zu überprüfen. Für eine abgetrennte GPG-Signaturdatei würden Sie das mit dem Befehl @code{gpg --verify} tun. @item Nehmen Sie sich die Zeit, eine passende Zusammenfassung und Beschreibung für das Paket zu verfassen. Unter @xref{Zusammenfassungen und Beschreibungen} finden Sie dazu einige Richtlinien. @item Verwenden Sie @code{guix lint @var{Paket}}, wobei @var{Paket} das neue oder geänderte Paket bezeichnet, und beheben Sie alle gemeldeten Fehler (@pxref{Aufruf von guix lint}). @item Stellen Sie sicher, dass das Paket auf Ihrer Plattform erstellt werden kann, indem Sie @code{guix build @var{Paket}} ausführen. @item @cindex gebündelt Achten Sie darauf, dass im Paket keine Software gebündelt mitgeliefert wird, die bereits in separaten Paketen zur Verfügung steht. Manchmal enthalten Pakete Kopien des Quellcodes ihrer Abhängigkeiten, um Nutzern die Installation zu erleichtern. Als eine Distribution wollen wir jedoch sicherstellen, dass solche Pakete die schon in der Distribution verfügbare Fassung benutzen, sofern es eine gibt. Dadurch wird sowohl der Ressourcenverbrauch optimiert (die Abhängigkeit wird so nur einmal erstellt und gespeichert) als auch der Distribution die Möglichkeit gegeben, ergänzende Änderungen durchzuführen, um beispielsweise Sicherheitsaktualisierungen für ein bestimmtes Paket an nur einem Ort einzuspielen, die aber das gesamte System betreffen — gebündelt mitgelieferte Kopien würden dies verhindern. @item Schauen Sie sich das von @command{guix size} ausgegebene Profil an (@pxref{Aufruf von guix size}). Dadurch können Sie Referenzen auf andere Pakete finden, die ungewollt vorhanden sind. Dies kann auch dabei helfen, zu entscheiden, ob das Paket aufgespalten werden sollte (@pxref{Pakete mit mehreren Ausgaben.}) und welche optionalen Abhängigkeiten verwendet werden sollten. @item Achten Sie bei wichtigen Änderungen darauf, dass abhängige Pakete (falls vorhanden) nicht von der Änderung beeinträchtigt werden; @code{guix refresh --list-dependent @var{Paket}} hilft Ihnen dabei (@pxref{Aufruf von guix refresh}). @c =========================================================================== @c @c This file was generated with po4a. Translate the source file. @c @c =========================================================================== @c See . @cindex Branching-Strategie @cindex Neuerstellungs-Zeitplan Je nachdem, wieviele abhängige Pakete es gibt, und entsprechend wieviele Neuerstellungen dadurch nötig würden, finden Commits auf anderen Branches statt, nach ungefähr diesen Regeln: @table @asis @item 300 abhängige Pakete oder weniger @code{master}-Branch (störfreie Änderungen). @item zwischen 300 und 1200 abhängige Pakete @code{staging}-Branch (störfreie Änderungen). Dieser Branch wird circa alle 3 Wochen in @code{master} gemerget. Themenbezogene Änderungen (z.B. eine Aktualisierung der GNOME-Plattform) können stattdessen auch auf einem eigenen Branch umgesetzt werden (wie @code{gnome-updates}). @item mehr als 1200 abhängige Pakete @code{core-updates}-Branch (kann auch größere und womöglich andere Software beeinträchtigende Änderungen umfassen). Dieser Branch wird planmäßig in @code{master} alle 2,5 Monate oder so gemerget. @end table All these branches are @uref{https://hydra.gnu.org/project/gnu, tracked by our build farm} and merged into @code{master} once everything has been successfully built. This allows us to fix issues before they hit users, and to reduce the window during which pre-built binaries are not available. @c TODO: It would be good with badges on the website that tracks these @c branches. Or maybe even a status page. Generally, branches other than @code{master} are considered @emph{frozen} if there has been a recent evaluation, or there is a corresponding @code{-next} branch. Please ask on the mailing list or IRC if unsure where to place a patch. @item @cindex Determinismus, von Erstellungsprozessen @cindex Reproduzierbare Erstellungen, Überprüfung Überprüfen Sie, ob der Erstellungsprozess deterministisch ist. Dazu prüfen Sie typischerweise, ob eine unabhängige Erstellung des Pakets genau dasselbe Ergebnis wie Ihre Erstellung hat, Bit für Bit. Dies können Sie leicht tun, indem Sie dasselbe Paket mehrere Male hintereinander auf Ihrer Maschine erstellen (@pxref{Aufruf von guix build}): @example guix build --rounds=2 mein-paket @end example Dies reicht aus, um eine ganze Klasse häufiger Ursachen von Nichtdeterminismus zu finden, wie zum Beispiel Zeitstempel oder zufallsgenerierte Ausgaben im Ergebnis der Erstellung. Eine weitere Möglichkeit ist, @command{guix challenge} (@pxref{Aufruf von guix challenge}) zu benutzen. Sie können es ausführen, sobald ein Paket commitet und von @code{hydra.gnu.org} erstellt wurde, um zu sehen, ob dort dasselbe Ergebnis wie bei Ihnen geliefert wurde. Noch besser: Finden Sie eine andere Maschine, die das Paket erstellen kann, und führen Sie @command{guix publish} aus. Da sich die entfernte Erstellungsmaschine wahrscheinlich von Ihrer unterscheidet, können Sie auf diese Weise Probleme durch Nichtdeterminismus erkennen, die mit der Hardware zu tun haben — zum Beispiel die Nutzung anderer Befehlssatzerweiterungen — oder mit dem Betriebssystem-Kernel — zum Beispiel, indem @code{uname} oder @file{/proc}-Dateien verwendet werden. @item Beim Schreiben von Dokumentation achten Sie bitte auf eine geschlechtsneutrale Wortwahl, wenn Sie sich auf Personen beziehen, wie @uref{https://en.wikipedia.org/wiki/Singular_they, »they«@comma{} »their«@comma{} »them« im Singular}, und so weiter. @item Stelllen Sie sicher, dass Ihr Patch nur einen Satz zusammengehöriger Änderungen umfasst. Das Zusammenfassen nicht zusammengehöriger Änderungen erschwert und bremst das Durchsehen Ihres Patches. Beispiele für nicht zusammengehörige Änderungen sind das Hinzufügen mehrerer Pakete auf einmal, oder das Aktualisieren eines Pakets auf eine neue Version zusammen mit Fehlerbehebungen für das Paket. @item Bitte befolgen Sie unsere Richtlinien für die Code-Formatierung, womöglich wollen Sie dies automatisch tun lassen durch das Skript @command{etc/indent-code.el} (@pxref{Formatierung von Code}). @item When possible, use mirrors in the source URL (@pxref{Aufruf von guix download}). Use reliable URLs, not generated ones. For instance, GitHub archives are not necessarily identical from one generation to the next, so in this case it's often better to clone the repository. Don't use the @command{name} field in the URL: it is not very useful and if the name changes, the URL will probably be wrong. @end enumerate Bitte benutzen Sie @samp{[PATCH] @dots{}} als Betreff, wenn Sie einen Patch an die Mailing-Liste schicken. Sie können dazu Ihr E-Mail-Programm oder den Befehl @command{git send-email} benutzen (@pxref{Senden einer Patch-Reihe}). Wir bevorzugen es, Patches als reine Textnachrichten zu erhalten, entweder eingebettet (inline) oder als MIME-Anhänge. Sie sind dazu angehalten, zu überprüfen, ob Ihr Mail-Programm solche Dinge wie Zeilenumbrüche oder die Einrückung verändert, wodurch die Patches womöglich nicht mehr funktionieren. Wenn dadurch ein Fehler behoben wurde, schließen Sie bitte den Thread, indem Sie eine E-Mail an @email{@var{NNN}-done@@debbugs.gnu.org} senden. @unnumberedsubsec Senden einer Patch-Reihe @anchor{Senden einer Patch-Reihe} @cindex Patch-Reihe @cindex @code{git send-email} @cindex @code{git-send-email} @c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html Wenn Sie eine Patch-Reihe senden (z.B. mit @code{git send-email}), schicken Sie bitte als Erstes eine Nachricht an @email{guix-patches@@gnu.org} und dann nachfolgende Patches an @email{@var{NNN}@@debbugs.gnu.org}, um sicherzustellen, dass sie zusammen bearbeitet werden. Siehe @uref{https://debbugs.gnu.org/Advanced.html, die Debbugs-Dokumentation} für weitere Informationen.