doc/contributing.de.texi

   1 @node Mitwirken
   2 @chapter Mitwirken
   3
   4 Dieses Projekt basiert auf Kooperation, daher benötigen wir Ihre Hilfe, um
   5 es wachsen zu lassen! Bitte kontaktieren Sie uns auf
   6 @email{guix-devel@@gnu.org} und @code{#guix} im Freenode-IRC-Netzwerk. Wir
   7 freuen uns auf Ihre Ideen, Fehlerberichte, Patches und alles, was hilfreich
   8 für das Projekt sein könnte. Besonders willkommen ist Hilfe bei der
   9 Erstellung von Paketen (@pxref{Paketrichtlinien}).
  10
  11 @cindex Verhaltensregeln, für Mitwirkende
  12 @cindex Verhaltenskodex für Mitwirkende
  13 Wir möchten eine angenehme, freundliche und von Belästigungen freie Umgebung
  14 bereitstellen, so dass jeder Beiträge nach seinen Fähigkeiten leisten
  15 kann. Zu diesem Zweck verwendet unser Projekt einen »Verhaltenskodex für
  16 Mitwirkende«, der von @url{http://contributor-covenant.org/} übernommen
  17 wurde. Eine übersetzte Fassung finden Sie auf
  18 @url{https://www.contributor-covenant.org/de/version/1/4/code-of-conduct}
  19 sowie eine mitgelieferte, englische Fassung in der Datei
  20 @file{CODE-OF-CONDUCT} im Quellbaum.
  21
  22 Von Mitwirkenden wird nicht erwartet, dass sie in Patches oder in der
  23 Online-Kommunikation ihre echten Namen preisgeben. Sie können einen
  24 beliebigen Namen oder ein Pseudonym ihrer Wahl verwenden.
  25
  26 @menu
  27 * Erstellung aus dem Git::   Das Neueste und Beste.
  28 * Guix vor der Installation ausführen::  Hacker-Tricks.
  29 * Perfekt eingerichtet::     Die richtigen Werkzeuge.
  30 * Code-Stil::                Wie Mitwirkende hygienisch arbeiten.
  31 * Einreichen von Patches::   Teilen Sie Ihre Arbeit.
  32 @end menu
  33
  34 @node Erstellung aus dem Git
  35 @section Erstellung aus dem Git
  36
  37 Wenn Sie an Guix selbst hacken wollen, ist es empfehlenswert, dass Sie die
  38 neueste Version aus dem Git-Softwarebestand verwenden:
  39
  40 @example
  41 git clone https://git.savannah.gnu.org/git/guix.git
  42 @end example
  43
  44 Wenn Sie Guix aus einem Checkout erstellen, sind außer den bereits in den
  45 Installationsanweisungen genannten Paketen weitere nötig
  46 (@pxref{Voraussetzungen}).
  47
  48 @itemize
  49 @item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
  50 @item @url{http://gnu.org/software/automake/, GNU Automake};
  51 @item @url{http://gnu.org/software/gettext/, GNU Gettext};
  52 @item @url{http://gnu.org/software/texinfo/, GNU Texinfo};
  53 @item @url{http://www.graphviz.org/, Graphviz};
  54 @item @url{http://www.gnu.org/software/help2man/, GNU Help2man (optional)}.
  55 @end itemize
  56
  57 Der einfachste Weg, eine Entwicklungsumgebung für Guix einzurichten, ist
  58 natürlich, Guix zu benutzen! Der folgende Befehl startet eine neue Shell, in
  59 der alle Abhängigkeiten und Umgebungsvariablen bereits eingerichtet sind, um
  60 an Guix zu arbeiten:
  61
  62 @example
  63 guix environment guix
  64 @end example
  65
  66 In @xref{Aufruf von guix environment} finden Sie weitere Informationen zu
  67 diesem Befehl. Zusätzliche Abhängigkeiten können mit @option{--ad-hoc}
  68 hinzugefügt werden:
  69
  70 @example
  71 guix environment guix --ad-hoc help2man git strace
  72 @end example
  73
  74 Führen Sie @command{./bootstrap} aus, um die Infrastruktur des
  75 Erstellungssystems mit Autoconf und Automake zu erstellen. Möglicherweise
  76 erhalten Sie eine Fehlermeldung wie diese:
  77
  78 @example
  79 configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
  80 @end example
  81
  82 @noindent
  83 Das bedeutet wahrscheinlich, dass Autoconf @file{pkg.m4} nicht finden
  84 konnte, welches von pkg-config bereitgestellt wird. Stellen Sie sicher, dass
  85 @file{pkg.m4} verfügbar ist. Gleiches gilt für den von Guile
  86 bereitgestellten Makrosatz @file{guile.m4}. Wenn Sie beispielsweise Automake
  87 in @file{/usr/local} installiert haben, würde in @file{/usr/share} nicht
  88 nach @file{.m4}-Dateien geschaut. In einem solchen Fall müssen Sie folgenden
  89 Befehl aufrufen:
  90
  91 @example
  92 export ACLOCAL_PATH=/usr/share/aclocal
  93 @end example
  94
  95 In @xref{Macro Search Path,,, automake, The GNU Automake Manual} finden Sie
  96 weitere Informationen.
  97
  98 Dann führen Sie wie gewohnt @command{./configure} aus. Achten Sie darauf,
  99 @code{--localstatedir=@var{Verzeichnis}} zu übergeben, wobei
 100 @var{Verzeichnis} der von Ihrer aktuellen Installation verwendete
 101 @code{localstatedir}-Wert ist (weitere Informationen auf @pxref{Der Store}).
 102
 103 Zum Schluss müssen Sie @code{make check} aufrufen, um die Tests auszuführen
 104 (@pxref{Die Testsuite laufen lassen}). Falls etwas fehlschlägt, werfen Sie einen
 105 Blick auf die Installationsanweisungen (@pxref{Installation}) oder senden
 106 Sie eine E-Mail an die @email{guix-devel@@gnu.org, Mailingliste}.
 107
 108
 109 @node Guix vor der Installation ausführen
 110 @section Guix vor der Installation ausführen
 111
 112 Um eine gesunde Arbeitsumgebung zu erhalten, ist es hilfreich, die im
 113 lokalen Quellbaum vorgenommenen Änderungen zunächst zu testen, ohne sie
 114 tatsächlich zu installieren. So können Sie zwischen Ihrem
 115 Endnutzer-»Straßenanzug« und Ihrem »Faschingskostüm« unterscheiden.
 116
 117 To that end, all the command-line tools can be used even if you have not run
 118 @code{make install}.  To do that, you first need to have an environment with
 119 all the dependencies available (@pxref{Erstellung aus dem Git}), and then simply
 120 prefix each command with @command{./pre-inst-env} (the @file{pre-inst-env}
 121 script lives in the top build tree of Guix; it is generated by
 122 @command{./configure}), as in@footnote{The @option{-E} flag to
 123 @command{sudo} guarantees that @code{GUILE_LOAD_PATH} is correctly set such
 124 that @command{guix-daemon} and the tools it uses can find the Guile modules
 125 they need.}:
 126
 127 @example
 128 $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
 129 $ ./pre-inst-env guix build hello
 130 @end example
 131
 132 @noindent
 133 Entsprechend, um eine Guile-Sitzung zu öffnen, die die Guix-Module benutzt:
 134
 135 @example
 136 $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
 137
 138 ;;; ("x86_64-linux")
 139 @end example
 140
 141 @noindent
 142 @cindex REPL
 143 @cindex Lese-Auswerten-Schreiben-Schleife
 144 @dots{} und auf einer REPL (@pxref{Using Guile Interactively,,, guile, Guile
 145 Reference Manual}):
 146
 147 @example
 148 $ ./pre-inst-env guile
 149 scheme@@(guile-user)> ,use(guix)
 150 scheme@@(guile-user)> ,use(gnu)
 151 scheme@@(guile-user)> (define snakes
 152                        (fold-packages
 153                          (lambda (package lst)
 154                            (if (string-prefix? "python"
 155                                                (package-name package))
 156                                (cons package lst)
 157                                lst))
 158                          '()))
 159 scheme@@(guile-user)> (length snakes)
 160 $1 = 361
 161 @end example
 162
 163 Das @command{pre-inst-env}-Skript richtet alle Umgebungsvariablen ein, die
 164 nötig sind, um dies zu ermöglichen, einschließlich @env{PATH} und
 165 @env{GUILE_LOAD_PATH}.
 166
 167 Note that @command{./pre-inst-env guix pull} does @emph{not} upgrade the
 168 local source tree; it simply updates the @file{~/.config/guix/current}
 169 symlink (@pxref{Aufruf von guix pull}).  Run @command{git pull} instead if you
 170 want to upgrade your local source tree.
 171
 172
 173 @node Perfekt eingerichtet
 174 @section Perfekt eingerichtet
 175
 176 Um perfekt für das Hacken an Guix eingerichtet zu sein, brauchen Sie an sich
 177 dasselbe wie um perfekt für das Hacken mit Guile (@pxref{Using Guile in
 178 Emacs,,, guile, Guile Reference Manual}).  Zunächst brauchen Sie mehr als
 179 ein Textverarbeitungsprogramm, Sie brauchen
 180 @url{http://www.gnu.org/software/emacs, Emacs}, ermächtigt vom wunderbaren
 181 @url{http://nongnu.org/geiser/, Geiser}.
 182
 183 Geiser ermöglicht interaktive und inkrementelle Entwicklung aus Emacs
 184 heraus: Code kann in Puffern kompiliert und ausgewertet werden. Zugang zu
 185 Online-Dokumentation (Docstrings) steht ebenso zur Verfügung wie
 186 kontextabhängige Vervollständigung, @kbd{M-.} um zu einer Objektdefinition
 187 zu springen, eine REPL, um Ihren Code auszuprobieren, und mehr
 188 (@pxref{Einführung,,, geiser, Geiser User Manual}). Zur bequemen
 189 Guix-Entwicklung sollten Sie Guiles Ladepfad so ergänzen, dass die
 190 Quelldateien in Ihrem Checkout gefunden werden.
 191
 192 @lisp
 193 ;; @r{Angenommen das Guix-Checkout ist in ~/src/guix.}
 194 (with-eval-after-load 'geiser-guile
 195   (add-to-list 'geiser-guile-load-path "~/src/guix"))
 196 @end lisp
 197
 198 Um den Code tatsächlich zu bearbeiten, bietet Emacs schon einen netten
 199 Scheme-Modus. Aber Sie dürfen auch
 200 @url{http://www.emacswiki.org/emacs/ParEdit, Paredit} nicht verpassen. Es
 201 bietet Hilfsmittel, um direkt mit dem Syntaxbaum zu arbeiten, und kann so
 202 zum Beispiel einen S-Ausdruck hochheben oder ihn umhüllen, ihn verschlucken
 203 oder den nachfolgenden S-Ausdruck verwerfen, etc.
 204
 205 @cindex Code-Schnipsel
 206 @cindex Vorlagen
 207 @cindex Tipparbeit sparen
 208 Wir bieten auch Vorlagen für häufige Git-Commit-Nachrichten und
 209 Paketdefinitionen im Verzeichnis @file{etc/snippets}. Diese Vorlagen können
 210 mit @url{http://joaotavora.github.io/yasnippet/, YASnippet} zusammen benutzt
 211 werden, um kurze Auslöse-Zeichenketten zu interaktiven Textschnipseln
 212 umzuschreiben. Vielleicht möchten Sie das Schnipselverzeichnis zu Ihrer
 213 @var{yas-snippet-dirs}-Variablen in Emacs hinzufügen.
 214
 215 @lisp
 216 ;; @r{Angenommen das Guix-Checkout ist in ~/src/guix.}
 217 (with-eval-after-load 'yasnippet
 218   (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))
 219 @end lisp
 220
 221 The commit message snippets depend on @url{https://magit.vc/, Magit} to
 222 display staged files.  When editing a commit message type @code{add}
 223 followed by @kbd{TAB} to insert a commit message template for adding a
 224 package; type @code{update} followed by @kbd{TAB} to insert a template for
 225 updating a package; type @code{https} followed by @kbd{TAB} to insert a
 226 template for changing the home page URI of a package to HTTPS.
 227
 228 Das Hauptschnipsel für @code{scheme-mode} wird ausgelöst, indem Sie
 229 @code{package...} gefolgt von @kbd{TAB} eintippen. Dieses Snippet fügt auch
 230 die Auslöse-Zeichenkette @code{origin...} ein, die danach weiter
 231 umgeschrieben werden kann. Das @code{origin}-Schnipsel kann wiederum andere
 232 Auslöse-Zeichenketten einfügen, die alle auf @code{...} enden, was selbst
 233 wieder weiter umgeschrieben werden kann.
 234
 235
 236 @node Code-Stil
 237 @section Code-Stil
 238
 239 Im Allgemeinen folgt unser Code den GNU Coding Standards (@pxref{Top,,,
 240 standards, GNU Coding Standards}). Da diese aber nicht viel über Scheme zu
 241 sagen haben, folgen hier einige zusätzliche Regeln.
 242
 243 @menu
 244 * Programmierparadigmen::    Wie Sie Ihre Elemente zusammenstellen.
 245 * Module::                   Wo Sie Ihren Code unterbringen.
 246 * Datentypen und Mustervergleich::  Implementierung von Datenstrukturen.
 247 * Formatierung von Code::    Schreibkonventionen.
 248 @end menu
 249
 250 @node Programmierparadigmen
 251 @subsection Programmierparadigmen
 252
 253 Scheme-Code wird in Guix auf rein funktionale Weise geschrieben. Eine
 254 Ausnahme ist Code, der mit Ein- und Ausgabe zu tun hat, und Prozeduren, die
 255 grundlegende Konzepte implementieren, wie zum Beispiel die Prozedur
 256 @code{memoize}.
 257
 258 @node Module
 259 @subsection Module
 260
 261 Guile-Module, die beim Erstellen nutzbar sein sollen, müssen im Namensraum
 262 @code{(guix build @dots{})} leben. Sie dürfen auf keine anderen Guix- oder
 263 GNU-Module Bezug nehmen. Jedoch ist es in Ordnung, wenn ein »wirtsseitiges«
 264 Modul ein erstellungsseitiges Modul benutzt.
 265
 266 Module, die mit dem weiteren GNU-System zu tun haben, sollten im Namensraum
 267 @code{(gnu @dots{})} und nicht in @code{(guix @dots{})} stehen.
 268
 269 @node Datentypen und Mustervergleich
 270 @subsection Datentypen und Mustervergleich
 271
 272 Im klassischen Lisp gibt es die Tendenz, Listen zur Darstellung von allem zu
 273 benutzen, und diese dann »händisch« zu durchlaufen mit @code{car},
 274 @code{cdr}, @code{cadr} und so weiter. Dieser Stil ist aus verschiedenen
 275 Gründen problematisch, insbesondere wegen der Tatsache, dass er schwer zu
 276 lesen, schnell fehlerbehaftet und ein Hindernis beim Melden von Typfehlern
 277 ist.
 278
 279 Guix-Code sollte angemessene Datentypen definieren (zum Beispiel mit
 280 @code{define-record-type*}) statt Listen zu missbrauchen. Außerdem sollte er
 281 das @code{(ice-9 match)}-Modul von Guile zum Mustervergleich benutzen,
 282 besonders mit Listen.
 283
 284 @node Formatierung von Code
 285 @subsection Formatierung von Code
 286
 287 @cindex Formatierung von Code
 288 @cindex Code-Stil
 289 Beim Schreiben von Scheme-Code halten wir uns an die üblichen
 290 Gepflogenheiten unter Scheme-Programmierern. Im Allgemeinen bedeutet das,
 291 dass wir uns an @url{http://mumble.net/~campbell/scheme/style.txt,
 292 Riastradh's Lisp Style Rules} halten. Es hat sich ergeben, dass dieses
 293 Dokument auch die Konventionen beschreibt, die im Code von Guile
 294 hauptsächlich verwendet werden. Es ist gut durchdacht und schön geschrieben,
 295 also lesen Sie es bitte.
 296
 297 Ein paar in Guix eingeführte Sonderformen, wie zum Beispiel das
 298 @code{substitute*}-Makro, haben abweichende Regeln für die Einrückung. Diese
 299 sind in der Datei @file{.dir-locals.el} definiert, die Emacs automatisch
 300 benutzt. Beachten Sie auch, dass Emacs-Guix einen Modus namens
 301 @code{guix-devel-mode} bereitstellt, der Guix-Code richtig einrückt und
 302 hervorhebt (@pxref{Development,,, emacs-guix, The Emacs-Guix Reference
 303 Manual}).
 304
 305 @cindex Einrückung, Code-
 306 @cindex Formatierung, Code-
 307 Falls Sie nicht Emacs verwenden, sollten Sie sicherstellen, dass Ihr Editor
 308 diese Regeln kennt. Um eine Paketdefinition automatisch einzurücken, können
 309 Sie auch Folgendes ausführen:
 310
 311 @example
 312 ./etc/indent-code.el gnu/packages/@var{Datei}.scm @var{Paket}
 313 @end example
 314
 315 @noindent
 316 Dadurch wird die Definition von @var{Paket} in
 317 @file{gnu/packages/@var{Datei}.scm} automatisch eingerückt, indem Emacs im
 318 Batch-Modus läuft. Um die Einrückung in einer gesamten Datei vorzunehmen,
 319 lassen Sie das zweite Argument weg:
 320
 321 @example
 322 ./etc/indent-code.el gnu/services/@var{Datei}.scm
 323 @end example
 324
 325 @cindex Vim, zum Editieren von Scheme-Code
 326 Wenn Sie Code mit Vim bearbeiten, empfehlen wir, dass Sie @code{:set
 327 autoindent} ausführen, damit Ihr Code automatisch eingerückt wird, während
 328 Sie ihn schreiben. Außerdem könnte Ihnen
 329 @uref{https://www.vim.org/scripts/script.php?script_id=3998,
 330 @code{paredit.vim}} dabei helfen, mit all diesen Klammern fertigzuwerden.
 331
 332 Wir fordern von allen Prozeduren auf oberster Ebene, dass sie über einen
 333 Docstring verfügen. Diese Voraussetzung kann jedoch bei einfachen, privaten
 334 Prozeduren im Namensraum @code{(guix build @dots{})} aufgeweicht werden.
 335
 336 Prozeduren sollten nicht mehr als vier positionsbestimmte Parameter
 337 haben. Benutzen Sie Schlüsselwort-Parameter für Prozeduren, die mehr als
 338 vier Parameter entgegennehmen.
 339
 340
 341 @node Einreichen von Patches
 342 @section Einreichen von Patches
 343
 344 Die Entwicklung wird mit Hilfe des verteilten Versionskontrollsystems Git
 345 durchgeführt. Daher ist eine ständige Verbindung zum Repository nicht
 346 unbedingt erforderlich. Wir begrüßen Beiträge in Form von Patches, die
 347 mittels @code{git format-patch} erstellt und an die Mailingliste
 348 @email{guix-patches@@gnu.org} geschickt werden.
 349
 350 Diese Mailing-Liste setzt auf einer Debbugs-Instanz auf, die zugänglich ist
 351 unter @uref{https://bugs.gnu.org/guix-patches}, wodurch wir den Überblick
 352 über Eingereichtes behalten können. Jede an diese Mailing-Liste gesendete
 353 Nachricht bekommt eine neue Folgenummer zugewiesen, so dass man eine
 354 Folge-Email zur Einreichung an @code{@var{NNN}@@debbugs.gnu.org} senden
 355 kann, wobei @var{NNN} für die Folgenummer steht (@pxref{Senden einer Patch-Reihe}).
 356
 357 Bitte schreiben Sie Commit-Logs im ChangeLog-Format (@pxref{Change Logs,,,
 358 standards, GNU Coding Standards}); dazu finden Sie Beispiele unter den
 359 bisherigen Commits.
 360
 361 Bevor Sie einen Patch einreichen, der eine Paketdefinition hinzufügt oder
 362 verändert, gehen Sie bitte diese Prüfliste durch:
 363
 364 @enumerate
 365 @item
 366 Wenn die Autoren der verpackten Software eine kryptographische Signatur für
 367 den Tarball der Veröffentlichung anbieten, so machen Sie sich bitte die
 368 Mühe, die Echtheit des Archivs zu überprüfen.  Für eine abgetrennte
 369 GPG-Signaturdatei würden Sie das mit dem Befehl @code{gpg --verify} tun.
 370
 371 @item
 372 Nehmen Sie sich die Zeit, eine passende Zusammenfassung und Beschreibung für
 373 das Paket zu verfassen. Unter @xref{Zusammenfassungen und Beschreibungen} finden Sie
 374 dazu einige Richtlinien.
 375
 376 @item
 377 Verwenden Sie @code{guix lint @var{Paket}}, wobei @var{Paket} das neue oder
 378 geänderte Paket bezeichnet, und beheben Sie alle gemeldeten Fehler
 379 (@pxref{Aufruf von guix lint}).
 380
 381 @item
 382 Stellen Sie sicher, dass das Paket auf Ihrer Plattform erstellt werden kann,
 383 indem Sie @code{guix build @var{Paket}} ausführen.
 384
 385 @item
 386 @cindex gebündelt
 387 Achten Sie darauf, dass im Paket keine Software gebündelt mitgeliefert wird,
 388 die bereits in separaten Paketen zur Verfügung steht.
 389
 390 Manchmal enthalten Pakete Kopien des Quellcodes ihrer Abhängigkeiten, um
 391 Nutzern die Installation zu erleichtern. Als eine Distribution wollen wir
 392 jedoch sicherstellen, dass solche Pakete die schon in der Distribution
 393 verfügbare Fassung benutzen, sofern es eine gibt. Dadurch wird sowohl der
 394 Ressourcenverbrauch optimiert (die Abhängigkeit wird so nur einmal erstellt
 395 und gespeichert) als auch der Distribution die Möglichkeit gegeben,
 396 ergänzende Änderungen durchzuführen, um beispielsweise
 397 Sicherheitsaktualisierungen für ein bestimmtes Paket an nur einem Ort
 398 einzuspielen, die aber das gesamte System betreffen — gebündelt
 399 mitgelieferte Kopien würden dies verhindern.
 400
 401 @item
 402 Schauen Sie sich das von @command{guix size} ausgegebene Profil an
 403 (@pxref{Aufruf von guix size}). Dadurch können Sie Referenzen auf andere
 404 Pakete finden, die ungewollt vorhanden sind. Dies kann auch dabei helfen, zu
 405 entscheiden, ob das Paket aufgespalten werden sollte (@pxref{Pakete mit mehreren Ausgaben.}) und welche optionalen Abhängigkeiten verwendet werden
 406 sollten.
 407
 408 @item
 409 Achten Sie bei wichtigen Änderungen darauf, dass abhängige Pakete (falls
 410 vorhanden) nicht von der Änderung beeinträchtigt werden; @code{guix refresh
 411 --list-dependent @var{Paket}} hilft Ihnen dabei (@pxref{Aufruf von guix refresh}).
 412
 413 @c ===========================================================================
 414 @c
 415 @c This file was generated with po4a. Translate the source file.
 416 @c
 417 @c ===========================================================================
 418 @c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
 419 @cindex Branching-Strategie
 420 @cindex Neuerstellungs-Zeitplan
 421 Je nachdem, wieviele abhängige Pakete es gibt, und entsprechend wieviele
 422 Neuerstellungen dadurch nötig würden, finden Commits auf anderen Branches
 423 statt, nach ungefähr diesen Regeln:
 424
 425 @table @asis
 426 @item 300 abhängige Pakete oder weniger
 427 @code{master}-Branch (störfreie Änderungen).
 428
 429 @item zwischen 300 und 1200 abhängige Pakete
 430 @code{staging}-Branch (störfreie Änderungen). Dieser Branch wird circa alle
 431 3 Wochen in @code{master} gemerget. Themenbezogene Änderungen (z.B. eine
 432 Aktualisierung der GNOME-Plattform) können stattdessen auch auf einem
 433 eigenen Branch umgesetzt werden (wie @code{gnome-updates}).
 434
 435 @item mehr als 1200 abhängige Pakete
 436 @code{core-updates}-Branch (kann auch größere und womöglich andere Software
 437 beeinträchtigende Änderungen umfassen). Dieser Branch wird planmäßig in
 438 @code{master} alle 2,5 Monate oder so gemerget.
 439 @end table
 440
 441 All these branches are @uref{https://hydra.gnu.org/project/gnu, tracked by
 442 our build farm} and merged into @code{master} once everything has been
 443 successfully built.  This allows us to fix issues before they hit users, and
 444 to reduce the window during which pre-built binaries are not available.
 445
 446 @c TODO: It would be good with badges on the website that tracks these
 447 @c branches.  Or maybe even a status page.
 448 Generally, branches other than @code{master} are considered @emph{frozen} if
 449 there has been a recent evaluation, or there is a corresponding @code{-next}
 450 branch.  Please ask on the mailing list or IRC if unsure where to place a
 451 patch.
 452
 453 @item
 454 @cindex Determinismus, von Erstellungsprozessen
 455 @cindex Reproduzierbare Erstellungen, Überprüfung
 456 Überprüfen Sie, ob der Erstellungsprozess deterministisch ist. Dazu prüfen
 457 Sie typischerweise, ob eine unabhängige Erstellung des Pakets genau dasselbe
 458 Ergebnis wie Ihre Erstellung hat, Bit für Bit.
 459
 460 Dies können Sie leicht tun, indem Sie dasselbe Paket mehrere Male
 461 hintereinander auf Ihrer Maschine erstellen (@pxref{Aufruf von guix build}):
 462
 463 @example
 464 guix build --rounds=2 mein-paket
 465 @end example
 466
 467 Dies reicht aus, um eine ganze Klasse häufiger Ursachen von
 468 Nichtdeterminismus zu finden, wie zum Beispiel Zeitstempel oder
 469 zufallsgenerierte Ausgaben im Ergebnis der Erstellung.
 470
 471 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
 472 und von @code{hydra.gnu.org} erstellt wurde, um zu sehen, ob dort dasselbe
 473 Ergebnis wie bei Ihnen geliefert wurde. Noch besser: Finden Sie eine andere
 474 Maschine, die das Paket erstellen kann, und führen Sie @command{guix
 475 publish} aus. Da sich die entfernte Erstellungsmaschine wahrscheinlich von
 476 Ihrer unterscheidet, können Sie auf diese Weise Probleme durch
 477 Nichtdeterminismus erkennen, die mit der Hardware zu tun haben — zum
 478 Beispiel die Nutzung anderer Befehlssatzerweiterungen — oder mit dem
 479 Betriebssystem-Kernel — zum Beispiel, indem @code{uname} oder
 480 @file{/proc}-Dateien verwendet werden.
 481
 482 @item
 483 Beim Schreiben von Dokumentation achten Sie bitte auf eine
 484 geschlechtsneutrale Wortwahl, wenn Sie sich auf Personen beziehen, wie
 485 @uref{https://en.wikipedia.org/wiki/Singular_they, »they«@comma{}
 486 »their«@comma{} »them« im Singular}, und so weiter.
 487
 488 @item
 489 Stelllen Sie sicher, dass Ihr Patch nur einen Satz zusammengehöriger
 490 Änderungen umfasst. Das Zusammenfassen nicht zusammengehöriger Änderungen
 491 erschwert und bremst das Durchsehen Ihres Patches.
 492
 493 Beispiele für nicht zusammengehörige Änderungen sind das Hinzufügen mehrerer
 494 Pakete auf einmal, oder das Aktualisieren eines Pakets auf eine neue Version
 495 zusammen mit Fehlerbehebungen für das Paket.
 496
 497 @item
 498 Bitte befolgen Sie unsere Richtlinien für die Code-Formatierung, womöglich
 499 wollen Sie dies automatisch tun lassen durch das Skript
 500 @command{etc/indent-code.el} (@pxref{Formatierung von Code}).
 501
 502 @item
 503 When possible, use mirrors in the source URL (@pxref{Aufruf von guix download}).  Use reliable URLs, not generated ones.  For instance, GitHub
 504 archives are not necessarily identical from one generation to the next, so
 505 in this case it's often better to clone the repository.  Don't use the
 506 @command{name} field in the URL: it is not very useful and if the name
 507 changes, the URL will probably be wrong.
 508
 509 @end enumerate
 510
 511 Bitte benutzen Sie @samp{[PATCH] @dots{}} als Betreff, wenn Sie einen Patch
 512 an die Mailing-Liste schicken. Sie können dazu Ihr E-Mail-Programm oder den
 513 Befehl @command{git send-email} benutzen (@pxref{Senden einer Patch-Reihe}). Wir bevorzugen es, Patches als reine Textnachrichten zu erhalten,
 514 entweder eingebettet (inline) oder als MIME-Anhänge. Sie sind dazu
 515 angehalten, zu überprüfen, ob Ihr Mail-Programm solche Dinge wie
 516 Zeilenumbrüche oder die Einrückung verändert, wodurch die Patches womöglich
 517 nicht mehr funktionieren.
 518
 519 Wenn dadurch ein Fehler behoben wurde, schließen Sie bitte den Thread, indem
 520 Sie eine E-Mail an @email{@var{NNN}-done@@debbugs.gnu.org} senden.
 521
 522 @unnumberedsubsec Senden einer Patch-Reihe
 523 @anchor{Senden einer Patch-Reihe}
 524 @cindex Patch-Reihe
 525 @cindex @code{git send-email}
 526 @cindex @code{git-send-email}
 527
 528 @c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
 529 Wenn Sie eine Patch-Reihe senden (z.B. mit @code{git send-email}), schicken
 530 Sie bitte als Erstes eine Nachricht an @email{guix-patches@@gnu.org} und
 531 dann nachfolgende Patches an @email{@var{NNN}@@debbugs.gnu.org}, um
 532 sicherzustellen, dass sie zusammen bearbeitet werden. Siehe
 533 @uref{https://debbugs.gnu.org/Advanced.html, die Debbugs-Dokumentation} für
 534 weitere Informationen.