diff options
Diffstat (limited to 'doc/contributing.de.texi')
| -rw-r--r-- | doc/contributing.de.texi | 537 |
1 files changed, 537 insertions, 0 deletions
diff --git a/doc/contributing.de.texi b/doc/contributing.de.texi new file mode 100644 index 0000000000..6c302ad70d --- /dev/null +++ b/doc/contributing.de.texi @@ -0,0 +1,537 @@ +@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 ist. 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 @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 behalten, 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), 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}. + +Beachten Sie, dass @command{./pre-inst-env guix pull} den lokalen Quellbaum +@emph{nicht} aktualisiert; es aktualisiert lediglich die symbolische +Verknüpfung @file{~/.config/guix/current} (@pxref{Aufruf von guix pull}). Um +Ihren lokalen Quellbaum zu aktualisieren, müssen Sie stattdessen +@command{git pull} benutzen. + + +@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-Modules 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 mit 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: + +@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 für 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 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 <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>. +@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 diese Branches werden kontinuierlich +@uref{https://hydra.gnu.org/project/gnu, auf unserer Build-Farm} erstellt +und in @code{master} gemerget, sobald alles erfolgreich erstellt worden +ist. Dadurch können wir Probleme beheben, bevor sie bei Nutzern auftreten, +und zudem das Zeitfenster, während dessen noch keine vorerstellten +Binärdateien verfügbar sind, verkürzen. + +@c TODO: It would be good with badges on the website that tracks these +@c branches. Or maybe even a status page. +Im Allgemeinen werden Branches außer @code{master} als @emph{unveränderlich} +angesehen, wenn sie kürzlich ausgewertet wurden oder ein entsprechender +@code{-next}-Branch existiert. Bitte fragen Sie auf der Mailing-Liste oder +IRC, wenn Sie sich nicht sicher sind, wo ein Patch eingespielt werden +sollte. + +@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. |