538 lines
23 KiB
Text
538 lines
23 KiB
Text
|
@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.
|