summaryrefslogtreecommitdiff
path: root/doc/contributing.de.texi
blob: 6c302ad70d34ae8db544345ef5bba05761a0aebc (about) (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
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.