@node Contribuer
@chapter Contribuer

Ce projet est un effort coopératif et nous avons besoin de votre aide pour
le faire grandir ! Contactez-nous sur @email{guix-devel@@gnu.org} et
@code{#guix} sur le réseau IRC Libera Chat.  Nous accueillons les idées, les
rapports de bogues, les correctifs et tout ce qui pourrait aider le projet.
Nous apprécions particulièrement toute aide sur la création de paquets
(@pxref{Consignes d'empaquetage}).

@cindex code de conduite, des contributeur·rices
@cindex convention de contribution
Nous souhaitons fournir un environnement chaleureux, amical et sans
harcèlement pour que tout le monde puisse contribuer au mieux de ses
capacités.  Pour cela notre projet a une « Convention de contribution »
adaptée de @url{http://contributor-covenant.org/}.  Vous pouvez trouver une
version locale dans le fichier @file{CODE-OF-CONDUCT} dans l'arborescence
des sources.

Les contributeur·rices n'ont pas besoin d'utiliser leur nom légal dans leurs
correctifs et leurs communications en ligne ; elles et ils peuvent utiliser
n'importe quel nom ou pseudonyme de leur choix.

@menu
* Construire depuis Git::    Toujours le plus récent.
* Lancer Guix avant qu'il ne soit installé::  Astuces pour les hackers.
* La configuration parfaite::  Les bons outils.
* Consignes d'empaquetage::  Faire grandir la distribution.
* Style de code::            Hygiène des contributeur·rices.
* Envoyer des correctifs::   Partager votre travail.
* Suivi des bogues et des correctifs::  Tout bien ranger.
* Accès en commit::         Pousser sur le dépôt officiel.
* Mettre à jour Guix::      Mettre à jour les définitions de paquets de 
                               Guix.
* Écrire de la documentation::  Améliorer la documentation de GNU Guix.
* Traduire Guix::            Faites en sorte que Guix parle votre langue.
@end menu

@node Construire depuis Git
@section Construire depuis Git

Si vous souhaitez travailler sur Guix lui-même, il est recommandé d'utiliser
la dernière version du dépôt Git :

@example
git clone https://git.savannah.gnu.org/git/guix.git
@end example

@cindex authentification, d'un extrait de Guix
Comment vous assurer que vous avez obtenu une copie authentique du dépôt ?
Pour cela, exécutez @command{guix git authenticate}, en lui transmettant le
commit et l'empreinte OpenPGP de l'@dfn{canal introduction} (@pxref{Invoquer guix git authenticate}) :

@c ===========================================================================
@c
@c This file was generated with po4a. Translate the source file.
@c
@c ===========================================================================

@c The commit and fingerprint below must match those of the channel
@c introduction in '%default-channels'.
@example
git fetch origin keyring:keyring
guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad \
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
@end example

@noindent
Cette commande se termine avec le code de sortie zéro en cas de succès ;
elle affiche un message d'erreur et quitte avec un code non zéro dans le cas
contraire.

Comme vous pouvez le voir, il y a un problème de poule et d'œuf : il faut
d'abord avoir installé Guix.  En général, vous installez Guix System
(@pxref{Installation du système}) ou Guix sur une autre distribution
(@pxref{Installation binaire}) ; dans les deux cas, vous vérifiez la
signature OpenPGP sur le support d'installation.  Cela "amorce" la chaîne de
confiance.

La manière la plus simple de configurer un environnement de développement
pour Guix est, bien sûr, d'utiliser Guix ! La commande suivante démarre un
nouveau shell où toutes les dépendances et les variables d'environnements
appropriées sont configurés pour travailler sur Guix :

@example
guix shell -D guix --pure
@end example

@xref{Invoquer guix shell}, pour plus d'informations sur cette commande.

Si vous ne pouvez pas utiliser Guix pour la construction de Guix depuis un
extrait, les paquets suivants sont requis en plus de ceux mentionnés dans
les instructions d'installation (@pxref{Prérequis}).

@itemize
@item @url{https://gnu.org/software/autoconf/, GNU Autoconf} ;
@item @url{https://gnu.org/software/automake/, GNU Automake} ;
@item @url{https://gnu.org/software/gettext/, GNU Gettext} ;
@item @url{https://gnu.org/software/texinfo/, GNU Texinfo} ;
@item @url{https://www.graphviz.org/, Graphviz} ;
@item @url{https://www.gnu.org/software/help2man/, GNU Help2man (facultatif)}.
@end itemize

Avec Guix, vous pouvez ajouter des dépendances supplémentaires en lançant
@command{guix shell} :

@example
guix shell -D guix help2man git strace --pure
@end example

Vous pouvez maintenant générer l'infrastructure du système de construction
avec Autoconf et Automake :

@example
./bootstrap
@end example

Si vous obtenez une erreur de ce type :

@example
configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
@end example

@noindent
cela signifie probablement qu'Autoconf n'a pas pu trouver @file{pkg.m4} qui
est fournit par pkg-config.  Assurez-vous que @file{pkg.m4} est disponible.
C'est aussi vrai pour l'ensemble de macros de @file{guile.m4} fournies par
Guile.  Par exemple, si vous avez installé Automake dans @file{/usr/local},
il ne cherchera pas les fichiers @file{.m4} dans @file{/usr/share}.  Dans ce
case vous devez invoquer la commande suivante :

@example
export ACLOCAL_PATH=/usr/share/aclocal
@end example

@xref{Macro Search Path,,, automake, The GNU Automake Manual}, pour plus
d'information.

Ensuite lancez :

@example
./configure --localstatedir=/var
@end example

@noindent
… où @var{-var} est la valeur @code{localstatedir} habituelle (@pxref{Le dépôt} pour plus d'informations à ce propos). Remarquez que vous n'allez
probablement pas lancer @command{make install} à la fin (vous n'avez pas
besoin de la faire) mais il est toujours important de passer le bon
@code{localstatedir}.

Enfin, vous pouvez construire Guix et, si vous le souhaitez, lancer les
tests (@pxref{Lancer la suite de tests}) :

@example
make
make check
@end example

@noindent
Si quelque chose échoue, jetez un œil aux instructions d'installation
(@pxref{Installation}) ou envoyez un message à la liste
@email{guix-devel@@gnu.org}.

À partir de maintenant, vous pouvez authentifier tous les commits de votre
extrait en lançant :

@example
make authenticate
@end example

La première exécution prend quelques minutes, mais les exécutions suivantes
seront plus rapides.

Ou bien, si la configuration de votre dépôt Git local ne correspond pas à la
configuration par défaut, vous pouvez fournir la référence pour la branche
@code{keyring} dans la variable @code{GUIX_GIT_KEYRING}.  L'exemple suivant
suppose que vous avez un dépôt distant nommé @samp{myremote} qui pointe vers
le dépôt officiel :

@example
make authenticate GUIX_GIT_KEYRING=myremote/keyring
@end example

@quotation Remarque
Nous vous conseillons d'exécuter @command{make authenticate} après chaque
invocation de @command{git pull}.  Cela vous garantit de continuer à
recevoir des modifications valables dans le dépôt.
@end quotation

Après la mise à jour du dépôt, @command{make} peut échouer avec une erreur
semblable à celle de l'exemple suivant :

@example
error: failed to load 'gnu/packages/dunst.scm':
ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <origin>>: record ABI mismatch; recompilation needed
@end example

Cela signifie qu'un des types d'enregistrement que Guix définie (dans cet
exemple, l'enregistrement @code{origin}) a changé, et que l'entièreté de
guix doit être recompilé pour prendre ce changement en compte. Pour ce
faire, lancez @command{make clean-go} suivi de @command{make}.

@node Lancer Guix avant qu'il ne soit installé
@section Lancer Guix avant qu'il ne soit installé

Pour garder un environnement de travail sain, il est utile de tester les
changement localement sans les installer pour de vrai.  Pour pouvoir
distinguer votre rôle « d'utilisateur·rice final·e » de celui parfois haut
en couleur de « développeur·euse ».

Pour cela, tous les outils en ligne de commande sont utilisables même sans
avoir lancé @code{make install}.  Pour faire cela, vous devez d'abord avoir
un environnement avec toutes les dépendances disponibles (@pxref{Construire depuis Git}), et puis préfixer simplement chaque commande avec
@command{./pre-inst-env} (le script @file{pre-inst-env} se trouve dans le
répertoire de plus haut niveau de l'arborescence des sources de Guix ; il
est généré en lançant @command{./bootstrap} suivit de
@command{./configure}).  À titre d'exemple, voici comment construire le
paquet @code{hello} tel que défini dans votre arborescence de travail (cela
suppose que @command{guix-daemon} fonctionne déjà sur votre système ; c'est
OK si c'est une version différente) :

@example
$ ./pre-inst-env guix build hello 
@end example

@noindent
De même, pour une session Guile qui utilise les modules Guix :

@example
$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'

;;; ("x86_64-linux")
@end example

@noindent
@cindex REPL
@cindex read-eval-print loop
@dots{} et pour une REPL (@pxref{Utiliser Guix de manière interactive}) :

@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

Si vous travaillez sur le démon et son code supporté ou si
@command{guix-daemon} n'est pas déjà lancé sur votre système, vous pouvez le
lancer directement depuis l'arborescence de construction@footnote{Le drapeau
@option{-E} de @command{sudo} garantit que @code{GUILE_LOAD_PATH} est
correctement configuré de sorte que @command{guix-daemon} et les outils
qu'il utilise puissent trouver les modules Guile dont ils ont besoin.} :

@example
$ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
@end example

Le script @command{pre-inst-env} paramètre toutes les variables
d'environnement nécessaires, dont @env{PATH} et @env{GUILE_LOAD_PATH}.

Remarquez que @command{./pre-inst-env guix pull} ne met @emph{pas} à jour
l'arborescence des sources locale ; cela met seulement à jour le lien
symbolique de @file{~/.config/guix/current} (@pxref{Invoquer guix pull}).
Lancez @command{git pull} à la place si vous voulez mettre à jour votre
arborescence des source locale.

Parfois, surtout si vous avez récemment mis à jour votre dépôt, lancer
@command{./pre-inst-env} affichera des messages semblables à l'exemple
suivant :

@example
;;; note: source file /home/user/projects/guix/guix/progress.scm
;;;       newer than compiled /home/user/projects/guix/guix/progress.go
@end example

Ce n'est qu'une remarque et vous pouvez l'ignorer sans problème. Vous pouvez
vous débarrasser de ce message en lançant @command{make -j4}. Jusqu'à ce que
vous fassiez cela, Guile sera un tout petit peu plus lent parce qu'il doit
interpréter le code au lieu d'utiliser les fichiers objets Guile
(@file{.go}) précompilés.

Vous pouvez lancer @command{make} automatiquement quand vous travaillez avec
@command{watchexec} du paquet @code{watchexec}. Par exemple, pour construire
de nouveau à chaque fois que vous modifiez un fichier de paquet lancez
@samp{watchexec -w gnu/packages -- make -j4}.

@node La configuration parfaite
@section La configuration parfaite

La configuration parfaite pour travailler sur Guix est simplement la
configuration parfaite pour travailler en Guile (@pxref{Using Guile in Emacs,,, guile, Guile Reference Manual}).  Tout d'abord, vous avez besoin de
mieux qu'un éditeur de texte, vous avez besoin de
@url{http://www.gnu.org/software/emacs, Emacs}, amélioré par le superbe
@url{http://nongnu.org/geiser/, Geiser}.  Pour paramétrer cela, lancez :

@example
guix install emacs guile emacs-geiser emacs-geiser-guile
@end example

Geiser permet le développement interactif et incrémental depuis Emacs : la
compilation du code et son évaluation depuis les tampons, l'accès à la
documentation en ligne (docstrings), la complétion sensible au contexte,
@kbd{M-.} pour sauter à la définition d'un objet, un REPL pour tester votre
code, et bien plus (@pxref{Introduction,,, geiser, Geiser User Manual}).
Pour travailler confortablement sur Guix, assurez-vous de modifier le chemin
de chargement de Guile pour qu'il trouve les fichiers source de votre dépôt
:

@lisp
;; @r{Si l'extrait est dans ~/src/guix.}
(with-eval-after-load 'geiser-guile
  (add-to-list 'geiser-guile-load-path "~/src/guix"))
@end lisp

Pour effectivement éditer le code, Emacs a déjà un très bon mode Scheme.
Mais en plus de ça, vous ne devez pas rater
@url{http://www.emacswiki.org/emacs/ParEdit, Paredit}.  Il fournit des
fonctionnalités pour opérer directement sur l'arbre de syntaxe, comme
relever une s-expression ou l'envelopper, absorber ou rejeter la
s-expression suivante, etc.

@cindex extraits de code
@cindex modèles
@cindex réduire la quantité de code commun
Nous fournissons aussi des modèles pour les messages de commit git courants
et les définitions de paquets dans le répertoire @file{etc/snippets}.  Ces
modèles s'utilisent pour étendre de courtes phrases d'amorce en des bouts de
texte interactifs. Si vous utilisez
@url{http://joaotavora.github.io/yasnippet/, YASnippet}, vous voudrez
peut-être ajouter le répertoire des modèles, @file{etc/snippets/yas}, dans
la variable d'environnement @var{yas-snippet-dirs}. Si vous utilisez
@url{https://github.com/minad/tempel/, Tempel}, vous voudrez peut-être
ajouter le chemin @file{etc/snippets/tempel/*} dans la variable
@var{tempel-path} d'Emacs.

@lisp
;; @r{En supposant que le dépôt git de Guix est dans ~/src/guix.}
;; @r{Configuration Yasnippet}
(with-eval-after-load 'yasnippet
  (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets/yas"))
;; @r{Configuration Tempel}
(with-eval-after-load 'tempel
   ;; S'assure que tempel-path est une liste — elle peut aussi être une chaine.
   (unless (listp 'tempel-path)
     (setq tempel-path (list tempel-path)))
   (add-to-list 'tempel-path "~/src/guix/etc/snippets/tempel/*"))
@end lisp

Les extraits de messages de commit dépendent de @url{https://magit.vc/,
Magit} pour afficher les fichiers sélectionnés.  Lors de la modification
d'un message de commit, tapez @code{add} suivi de @kbd{TAB} pour insérer un
modèle de message de commit pour ajouter un paquet ; tapez @code{update}
suivi de @kbd{TAB} pour insérer un modèle pour la mise à jour d'un paquet ;
tapez @code{https} suivi de @kbd{TAB} pour insérer un modèle pour le
changement à HTTPS de l'URI de la page d'accueil.

L'extrait principal pour @code{scheme-mode} est lancé en tapant
@code{package…} suivi par @kbd{TAB}.  Cet extrait insère aussi la chaîne de
déclenchement @code{origin…}, qui peut aussi être étendue.  L'extrait
@code{origin} lui-même peut aussi insérer des chaînes de déclenchement qui
finissent sur @code{…}, qui peuvent aussi être étendues.

@cindex insérer ou mettre à jour la ligne de copyright
@cindex @code{M-x guix-copyright}
@cindex @code{M-x copyright-update}
De plus, nous fournissons l'insertion et la mise à jour automatique d'une
ligne de copyright dans @file{etc/copyright.el}.  Vous voudrez sans doute
indiquer votre nom complet, adresse de courriel et charger le fichier.

@lisp
(setq user-full-name "Alice Doe")
(setq user-mail-address "alice@@mail.org")
;; @r{En supposant que le dépôt Guix est dans ~/src/guix.}
(load-file "~/src/guix/etc/copyright.el")
@end lisp

Pour insérer une ligne de copyright à la ligne actuelle invoquez @code{M-x
guix-copyright}.

Pour mettre à jour une ligne de copyright vous devez spécifier un
@code{copyright-names-regexp}.

@lisp
(setq copyright-names-regexp
      (format "%s <%s>" user-full-name user-mail-address))
@end lisp

Vous pouvez vérifier si votre ligne de copyright est à jour en évaluant
@code{M-x copyright-update}.  Si vous voulez le faire automatiquement après
chaque sauvegarde de tampon ajoutez @code{(add-hook 'after-save-hook
'copyright-update)} dans Emacs.

@node Consignes d'empaquetage
@section Consignes d'empaquetage

@cindex paquets, création
La distribution GNU est jeune et vos paquets préférés peuvent manquer.
Cette section décrit comment vous pouvez aider à agrandir la distribution.

Les paquets de logiciels libres sont habituellement distribués sous forme
@dfn{d'archives de sources} — typiquement des fichiers @file{.tar.gz}
contenant tous les fichiers sources.  Ajouter un paquet à la distribution
signifie en substance deux choses : ajouter une @dfn{recette} qui décrit
comment construire le paquet, avec une liste d'autres paquets requis pour le
construire, et ajouter des @dfn{métadonnées de paquet} avec la recette,
comme une description et une licence.

Dans Guix, toutes ces informations sont incorporées dans les
@dfn{définitions de paquets}.  Les définitions de paquets fournissent une
vue de haut-niveau du paquet.  Elles sont écrites avec la syntaxe du langage
de programmation Scheme ; en fait, pour chaque paquet nous définissons une
variable liée à la définition et exportons cette variable à partir d'un
module (@pxref{Modules de paquets}).  Cependant, il n'est @emph{pas} nécessaire
d'avoir une connaissance approfondie du Scheme pour créer des paquets.  Pour
plus d'informations sur les définitions des paquets, @pxref{Définition des paquets}.

Une fois une définition de paquet en place, stocké dans un fichier de
l'arborescence des sources de Guix, il peut être testé avec la commande
@command{guix build} (@pxref{Invoquer guix build}).  Par exemple, en
supposant que le nouveau paquet s'appelle @code{gnew}, vous pouvez lancer
cette commande depuis l'arborescence de construction de Guix (@pxref{Lancer Guix avant qu'il ne soit installé}) :

@example
./pre-inst-env guix build gnew --keep-failed
@end example

Utiliser @code{--keep-failed} rend facile le débogage des échecs car il
fournit l'accès à l'arborescence de construction qui a échouée.  Une autre
sous-commande utile pour le débogage est @code{--log-file}, pour accéder au
journal de construction.

Si le paquet n'est pas connu de la commande @command{guix}, il se peut que
le fichier source ait une erreur de syntaxe, ou qu'il manque une clause
@code{define-public} pour exporter la variable du paquet.  Pour comprendre
cela, vous pouvez charger le module depuis Guile pour avoir plus
d'informations sur la véritable erreur :

@example
./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
@end example

Une fois que votre paquet est correctement construit, envoyez-nous un
correctif (@pxref{Contribuer}).  Enfin, si vous avez besoin d'aide, nous
serons ravis de vous aider aussi.  Une fois que le correctif soumis est
commité dans le dépôt Guix, le nouveau paquet est automatiquement construit
sur les plate-formes supportées par
@url{https://@value{SUBSTITUTE-SERVER-1}, notre système d'intégration
continue}.

@cindex substitution
On peut obtenir la nouvelle définition du paquet simplement en lançant
@command{guix pull} (@pxref{Invoquer guix pull}). Lorsque
@code{@value{SUBSTITUTE-SERVER-1}} a fini de construire le paquet,
l'installation du paquet y télécharge automatiquement les binaires
(@pxref{Substituts}). La seule intervention humaine requise est pendant la
revue et l'application du correctif.


@menu
* Liberté logiciel::        Ce que la distribution peut contenir.
* Conventions de nommage::   Qu'est-ce qu'un bon nom ?
* Numéros de version::      Lorsque le nom n'est pas suffisant.
* Synopsis et descriptions::  Aider les utilisateur·rices à trouver le bon 
                                paquet.
* Substituts ou Phases::     Qu'il s'agisse d'un substitut ou d'une phase de 
                               construction.
* Paquets Emacs::            Votre dose d'Elisp.
* Modules Python::           Un peu de comédie anglaise.
* Modules Perl::             Petites perles.
* Paquets Java::             Pause café.
* Paquets Rust::             Attention à l'oxydation.
* Paquets elm::              Arborescence de code pour navigateur
* Polices de caractères::   À fond les fontes.
@end menu

@node Liberté logiciel
@subsection Liberté logiciel

@c Adapted from http://www.gnu.org/philosophy/philosophy.html.
@cindex logiciel libre
Le système d'exploitation GNU a été développé pour que les utilisatrices et
utilisateurs puissent utiliser leur ordinateur en toute liberté.  GNU est un
@dfn{logiciel libre}, ce qui signifie que chaque personne l'utilisant
bénéficie des @url{https://www.gnu.org/philosophy/free-sw.fr.html,quatre
libertés essentielles} : exécuter le programmer, étudier et modifier le
programme sous sa forme source, redistribuer des copies exactes et
distribuer les versions modifiées.  Les paquets qui se trouvent dans la
distribution GNU ne fournissent que des logiciels qui respectent ces quatre
libertés.

En plus, la distribution GNU suit les
@url{https://www.gnu.org/distros/free-system-distribution-guidelines.html,recommandations
pour les distributions systèmes libres}.  Entre autres choses, ces
recommandations rejettent les microgiciels non libres, les recommandations
de logiciels non libres et discute des façon de gérer les marques et les
brevets.

Certaines sources amont autrement parfaitement libres contiennent une petite
partie facultative qui viole les recommandations ci-dessus, par exemple car
cette partie est du code non-libre.  Lorsque cela arrive, les éléments en
question sont supprimés avec des correctifs ou des bouts de codes appropriés
dans la forme @code{origin} du paquet (@pxref{Définition des paquets}).  De cette
manière, @code{guix build --source} renvoie la source « libérée » plutôt que
la source amont sans modification.


@node Conventions de nommage
@subsection Conventions de nommage

@cindex nom du paquet
Un paquet a en fait deux noms qui lui sont associés. Premièrement il y a le
nom de la @emph{variable Scheme}, celui qui suit @code{define-public}.  Par
ce nom, le paquet peut se faire connaître par le code Scheme, par exemple
comme entrée d'un autre paquet.  Deuxièmement, il y a la chaîne dans le
champ @code{name} d'une définition de paquet.  Ce nom est utilisé par les
commandes de gestion des paquets comme @command{guix package} et
@command{guix build}.

Les deux sont habituellement les mêmes et correspondent à la conversion en
minuscule du nom du projet choisi en amont, où les underscores sont
remplacés par des tirets.  Par exemple, GNUnet est disponible en tant que
@code{gnunet} et SDL_net en tant que @code{sdl-net}.

Une exception notable à cette règle est lorsque le nom du projet consiste en
un unique caractère, ou si un projet maintenu plus ancien avec le même nom
existe déjà — indépendamment de s'il a été empaqueté dans Guix on
nom. Utilisez votre bon sens pour éviter de rendre ces noms ambigües et de
leur enlever leur sens. Par exemple, le paquet Guix pour le shell nommé « s
» en amont est @code{s-shell} et @emph{pas} @code{s}. N'hésitez pas à
demander si vous êtes en panne d'inspiration.

Nous n'ajoutons pas de préfixe @code{lib} au bibliothèques de paquets, à
moins qu'il ne fasse partie du nom officiel du projet.  Mais @pxref{Modules Python} et @ref{Modules Perl}  pour des règles spéciales concernant les
modules pour les langages Python et Perl.

Les noms de paquets de polices sont gérés différemment, @pxref{Polices de caractères}.


@node Numéros de version
@subsection Numéros de version

@cindex version du paquet
Nous n'incluons en général que la dernière version d'un projet de logiciel
libre donné.  Mais parfois, par exemple pour des versions incompatibles de
bibliothèques, deux (ou plus) versions du même paquet sont requises.  Elles
ont besoin d'un nom de variable Scheme différent.  Nous utilisons le nom
défini dans @ref{Conventions de nommage} pour la version la plus récente ; les
versions précédentes utilisent le même nom, suffixé par @code{-} et le plus
petit préfixe du numéro de version qui permet de distinguer deux versions.

Le nom dans la définition du paquet est le même pour toutes les versions
d'un paquet et ne contient pas de numéro de version.

Par exemple, les version 2.24.20 et 3.9.12 de GTK+ peuvent être inclus de
cette manière :

@lisp
(define-public gtk+
  (package
    (name "gtk+")
    (version "3.9.12")
    ...))
(define-public gtk+-2
  (package
    (name "gtk+")
    (version "2.24.20")
    ...))
@end lisp
Si nous voulons aussi GTK+ 3.8.2, cela serait inclus de cette manière
@lisp
(define-public gtk+-3.8
  (package
    (name "gtk+")
    (version "3.8.2")
    ...))
@end lisp

@c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
@c for a discussion of what follows.
@cindex numéro de version, pour les instantanés des systèmes de contrôle de version
Parfois, nous incluons des paquets provenant d'instantanés de systèmes de
contrôle de version (VCS) au lieu de versions publiées formellement.  Cela
devrait rester exceptionnel, car c'est le rôle des développeurs amont de
spécifier quel est la version stable.  Cependant, c'est parfois nécessaire.
Donc, que faut-il mettre dans le champ @code{version} ?

Clairement, nous devons rendre l'identifiant de commit de l'instantané du
VCS visible dans la version, mais nous devons aussi nous assurer que la
version augmente de manière monotone pour que @command{guix package
--upgrade} puisse déterminer quelle version est la plus récente.  Comme les
identifiants de commits, notamment avec Git, n'augmentent pas, nous ajoutons
un numéro de révision qui nous augmentons à chaque fois que nous mettons à
jour vers un nouvel instantané.  La chaîne qui en résulte ressemble à cela :

@example
2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- ID du commit en amont
  |    |
  |    `--- révision du paquet Guix
  |
dernière version en amont
@end example

C'est une bonne idée de tronquer les identifiants dans le champ
@code{version} à disons 7 caractères.  Cela évite un problème esthétique (en
supposant que l'esthétique ait un rôle à jouer ici) et des problèmes avec
les limites de l'OS comme la longueur maximale d'un shebang (127 octets pour
le noyau Linux). Il y a des fonctions auxiliaires pour faire cela avec les
paquets qui utilisent @code{git-fetch} ou @code{hg-fetch} (voir plus
bas). Il vaut mieux cependant utiliser l'identifiant de commit complet dans
@code{origin}, pour éviter les ambiguïtés.  Une définition de paquet peut
ressembler à ceci :


@lisp
(define my-package
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;révision du paquet Guix
    (package
      (version (git-version "0.9" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "git://example.org/my-package.git")
                      (commit commit)))
                (sha256 (base32 "1mbikn@dots{}"))
                (file-name (git-file-name name version))))
      ;; @dots{}
      )))
@end lisp

@deffn {Procédure Scheme} git-version @var{VERSION} @var{REVISION} @var{COMMIT}
Renvoie la chaîne de version pour les paquets qui utilisent
@code{git-fetch}.

@lisp
(git-version "0.2.3" "0" "93818c936ee7e2f1ba1b315578bde363a7d43d05")
@result{} "0.2.3-0.93818c9"
@end lisp
@end deffn

@deffn {Procédure Scheme} hg-version @var{VERSION} @var{REVISION} @var{CHANGESET}
Renvoie la chaîne de version pour les paquets qui utilisent
@code{hg-fetch}. Cela fonctionne de la même manière que @code{git-fetch}.
@end deffn

@node Synopsis et descriptions
@subsection Synopsis et descriptions

@cindex description du paquet
@cindex résumé du paquet
Comme nous l'avons vu avant, chaque paquet dans GNU@tie{}Guix contient un
résumé et une description (@pxref{Définition des paquets}).  Les résumés et les
descriptions sont importants : ce sont eux que recherche @command{guix
package --search}, et c'est une source d'informations cruciale pour aider
les utilisateur·rices à déterminer si un paquet donné correspond à leurs
besoins.  En conséquence, il convient de prêter attention à leur contenu
lorsqu'on travaille sur un paquet.

Les résumés doivent commencer par une lettre capitale et ne doit pas finir
par un point.  Ils ne doivent pas commencer par « a » ou « the » (« un » ou
« le/la »), ce qui n'apporte généralement rien ; par exemple, préférez «
File-frobbing tool » (« Outil de frobage de fichier ») à « A tool that frobs
file » (« Un outil qui frobe les fichiers »).  Le résumé devrait dire ce que
le paquet est — p.@: ex.@: « Utilitaire du cœur de GNU (fichier, text,
shell) » — ou ce à quoi il sert — p.@: ex.@: le résumé de grep est « Affiche
des lignes correspondant à un motif ».

Gardez à l'esprit que le résumé doit avoir du sens pour un large public.
Par exemple « Manipulation d'alignements au format SAM » peut avoir du sens
pour un bioinformaticien chevronné, mais n'aidera pas ou pourra perdre une
audience de non-spécialistes.  C'est une bonne idée de créer un résumé qui
donne une idée du domaine d'application du paquet.  Dans cet exemple, cela
donnerait « Manipulation d'alignements de séquences de nucléotides », ce qui
devrait donner une meilleure idée à la personne qui le lit pour savoir si
c'est ce qu'elle recherche.

Les descriptions devraient faire entre cinq et dix lignes.  Utilisez des
phrases complètes, et évitez d'utiliser des acronymes sans les introduire
d'abord.  Évitez les expressions commerciales comme « world-leading », «
industrial-strength » et « next-generation » et évitez les superlatifs comme
« the most advanced » — ils ne sont pas utiles aux personnes qui cherchent
un paquet et semblent même un peu suspects.  À la place, essayez d'être
factuels, en mentionnant les cas d'utilisation et les fonctionnalités.

@cindex Balisage texinfo, dans les descriptions de paquets
Les descriptions peuvent inclure du balisage Texinfo, ce qui est utile pour
introduire des ornements comme @code{@@code} ou @code{@@dfn}, des listes à
points ou des hyperliens (@pxref{Overview,,, texinfo, GNU Texinfo}).
Cependant soyez prudents lorsque vous utilisez certains symboles, par
exemple @samp{@@} et les accolades qui sont les caractères spéciaux de base
en Texinfo (@pxref{Special Characters,,, texinfo, GNU Texinfo}).  Les
commandes et outils comme @command{guix show} prennent en charge le rendu.

Les résumés et les descriptions sont traduits par des volontaires
@uref{https://translate.fedoraproject.org/projects/guix/packages, sur
Weblate} pour que le plus de personnes possible puissent les lire dans leur
langue natale.  Les interfaces les recherchent et les affichent dans la
langue spécifiée par le paramètre de régionalisation actuel.

Pour permettre à @command{xgettext} de les extraire comme des chaînes
traduisibles, les résumés et les descriptions @emph{doivent être des chaînes
litérales}.  Cela signifie que vous ne pouvez pas utiliser
@code{string-append} ou @code{format} pour construire ces chaînes :

@lisp
(package
  ;; @dots{}
  (synopsis "Ceci est traduisible")
  (description (string-append "Ceci n'est " "*pas*" " traduisible.")))
@end lisp

La traduction demande beaucoup de travail, faites donc d'autant plus
attention à vos résumés et descriptions lorsque vous développez un paquet
car chaque changement peut demander du de travail de la part des
traducteur·rices.  Pour les aider, il est possible de donner des
recommandations ou des instructions qu'ils et elles pourront voir en
insérant des commentaires spéciaux comme ceci (@pxref{xgettext Invocation,,,
gettext, GNU Gettext}) :

@lisp
;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
(description "ARandR is designed to provide a simple visual front end
for the X11 resize-and-rotate (RandR) extension. @dots{}")
@end lisp

@node Substituts ou Phases
@subsection Substituts ou Phases

@cindex substituts, quand les utiliser
La différence entre l'utilisation d'un bout de code (snippet) dans origin et
une phase de construction pour modifier les sources d'un paquet peut être
particulièrement subtile. Les bouts de code dans origin sont en général
utilisés pour supprimer des fichiers indésirables, comme des bibliothèques
incluses, des sources non libres ou pour appliquer de simples
substitutions. La source dérivée d'un objet origin devrait produire une
source qui peut être utilisée pour construire le paquet sur n'importe quel
système pris en charge par le paquet en amont (c.-à-d.@:, être la source
correspondante). En particulier, les bouts de code dans origin ne doivent
pas inclure d'éléments du dépôt dans les sources ; de telles corrections
devraient plutôt être faites avec une phase de construction. Référez-vous à
la documentation sur l'enregistrement @code{origin} pour plus d'information
(@pxref{référence de origin}).

@node Paquets Emacs
@subsection Paquets Emacs

@cindex emacs, création de paquets
@cindex elips, création de paquets
Les paquets Emacs devraient plutôt utiliser le système de construction Emacs
(@pxref{emacs-build-system}), pour l'uniformité et les bénéfices apportés
par ses phases de construction, comme la génération automatique du fichier
autoloads et la compilation des sources. Comme il n'y a pas de manière
standardisée de lancer une suite de tests pour les paquets Emacs, les tests
sont désactivés par défaut. Lorsqu'une suite de tests est disponible, elle
devrait être activée en mettant l'argument @code{#:tests?} à
@code{#true}. Par défaut, la commande pour lancer les tests est
@command{make check}, mais on peut spécifier une autre commande via
l'argument @code{#:test-command}. L'argument @code{#:test-command} attend
une liste contenant une commande et ses arguments, à invoquer pendant la
phase @code{check}.

Les dépendances Elisp des paquets Emacs sont en général fournie dans
@code{propagated-inputs} lorsqu'elles sont requises à l'exécution. Comme
pour les autres paquets, les dépendances de test et de construction doivent
être spécifiées dans @code{native-inputs}.

Les paquets Emacs dépendent parfois de répertoires de ressources qui
devraient être installés avec les fichiers Elisp. L'argument
@code{#:include} peut être utilisé pour cela, en spécifiant une liste
d'expression régulières. La bonne pratique pour utiliser l'argument
@code{#:include} est d'étendre plutôt que de remplacer sa valeur par défaut
(accessible via la variable @code{%default-include}). Par exemple, un paquet
d'extension yasnippet inclut en général un répertoire @file{snippets}, qui
pourrait être copié vers le répertoire d'installation avec :

@lisp
#:include (cons "^snippets/" %default-include)
@end lisp

Lorsque vous rencontrez des problèmes, il est utile de vérifier la présence
de l'en-tête d'extension @code{Package-Requires} dans le fichier source
principal du paquet, et si les dépendances et leurs versions qui y sont
listées sont satisfaites.

@node Modules Python
@subsection Modules Python

@cindex python
Nous incluons actuellement Python 2 et Python 3, sous les noms de variables
Scheme @code{python-2} et @code{python} comme expliqué dans @ref{Numéros de version}.  Pour éviter la confusion et les problèmes de noms avec d'autres
langages de programmation, il semble désirable que le nom d'un paquet pour
un module Python contienne le mot @code{python}.

Certains modules ne sont compatibles qu'avec une version de Python, d'autres
avec les deux.  Si le paquet Toto ne compile qu'avec Python 3, on le nomme
@code{python-toto}.  S'il est compilé avec Python 2, on le nome
@code{python2-toto}.  Les paquets ne devraient être ajoutés que lorsqu'ils
sont nécessaires ; nous n'ajoutons pas les variantes Python 2 du paquet à
moins qu'on ne les utilise ensuite.

Si un projet contient déjà le mot @code{python}, on l'enlève, par exemple le
module python-dateutil est packagé sous les noms @code{python-dateutil} et
@code{python2-dateutil}.  Si le nom du projet commence par @code{py} (p.@:
ex.@: @code{pytz}), on le garde et on le préfixe comme décrit ci-dessus.

@quotation Remarque
Il y a actuellement deux systèmes de construction différents pour les
paquets Python dans Guix : @var{python-build-system} et
@var{pyproject-build-system}. Pendant longtemps, les paquets Python étaient
construits à partir d'un fichier @file{setup.py} à la spécification
informelle. Cela fonctionnait très bien, étant donné le succès de Python,
mais il était difficile de construire des outils par dessus. En conséquence,
de nombreuses alternatives ont émergé et la communauté a finalement retenu
un @url{https://peps.python.org/pep-0517, standard formel} pour spécifier
les prérequis de construction. @var{pyproject-build-system} est
l'implémentation de ce standard par Guix. Il est considéré comme «
expérimental » dans le sens où il ne prend pas encore en charge les divers
@emph{moteurs de construction} de PEP-517, mais nous vous encourageons à
l'essayer pour les nouveaux paquets Python et à rapporter tout problème que
vous rencontreriez. Il finira par être rendu obsolète et fusionné dans
@var{python-build-system}.
@end quotation

@subsubsection Spécifier les dépendances
@cindex entrées, pour les paquets Python

Les informations de dépendances pour les paquets Python se trouvent
généralement dans l'arborescence des source du paquet, avec plus ou moins de
précision : dans le fichier @file{pyproject.toml}, le fichier
@file{setup.py}, dans @file{requirements.txt} ou dans @file{tox.ini} (ce
dernier surtout pour les dépendances de test).

Votre mission, lorsque vous écrivez une recette pour un paquet Python, est
de faire correspondre ces dépendances au bon type « d'entrée »
(@pxref{référence de package, inputs}).  Bien que l'importeur @code{pypi} fasse
du bon boulot (@pxref{Invoquer guix import}), vous devriez vérifier la liste
suivant pour déterminer où va telle dépendance.

@itemize

@item
Nous empaquetons Python avec @code{setuptools} et @code{pip} installé par
défaut. Cela va changer, et nous vous encourageons à utiliser
@code{python-toolchain} si vous voulez un environnement de construction pour
Python.

@command{guix lint} vous avertira si @code{setuptools} ou @code{pip} sont
ajoutés en entrées natives car ils ne sont en général pas nécessaires.

@item
Les dépendances Python requises à l'exécutions vont dans
@code{propagated-inputs}.  Elles sont typiquement définies dans le mot-clef
@code{install_requires} dans @file{setup.py} ou dans le fichier
@file{requirements.txt}.

@item
Les paquets Python requis uniquement à la construction — p.@: ex.@: ceux
listés dans @code{build-system.requires} dans @file{pyproject.toml} ou dans
le mot-clef @code{setup_requires} de @file{setup.py} — ou les dépendances
seulement pour les tests — p.@: ex.@: ceux dans @code{tests_require} — vont
dans @code{native-inputs}.  La raison est qu'ils n'ont pas besoin d'être
propagés car ils ne sont pas requis à l'exécution et dans le cas d'une
compilation croisée, c'est l'entrée « native » qu'il nous faut.

Les cadriciels de tests @code{pytest}, @code{mock} et @code{nose} sont des
exemples.  Bien sûr si l'un de ces paquets est aussi requis à l'exécution,
il doit aller dans @code{propagated-inputs}.

@item
Tout ce qui ne tombe pas dans les catégories précédentes va dans
@code{inputs}, par exemple des programmes pour des bibliothèques C requises
pour construire des paquets Python avec des extensions C.

@item
Si un paquet Python a des dépendances facultatives (@code{extras_require}),
c'est à vous de décider de les ajouter ou non, en fonction du ratio entre
utilité et complexité (@pxref{Envoyer des correctifs, @command{guix size}}).

@end itemize


@node Modules Perl
@subsection Modules Perl

@cindex perl
Les programmes Perl utiles en soit sont nommés comme les autres paquets,
avec le nom amont en minuscule.  Pour les paquets Perl contenant une seule
classe, nous utilisons le nom de la classe en minuscule, en remplaçant les
occurrences de @code{::} par des tirets et en préfixant le tout par
@code{perl-}.  Donc la classe @code{XML::Parser} devient
@code{perl-xml-parser}.  Les modules contenant plusieurs classes gardent
leur nom amont en minuscule et sont aussi préfixés par @code{perl-}.  Ces
modules tendent à avoir le mot @code{perl} quelque part dans leur nom, que
nous supprimons en faveur du préfixe.  Par exemple, @code{libwww-perl}
devient @code{perl-libwww}.


@node Paquets Java
@subsection Paquets Java

@cindex java
Le programmes Java utiles en soit sont nommés comme les autres paquets, avec
le nom amont en minuscule.

Pour éviter les confusions et les problèmes de nom avec d'autres langages de
programmation, il est désirable que le nom d'un paquet Java soit préfixé par
@code{java-}.  Si un projet contient déjà le mot @code{java}, nous le
supprimons, par exemple le paquet @code{ngsjava} est empaqueté sous le nom
@code{java-ngs}.

Pour les paquets java contenant une seul classe ou une petite hiérarchie de
classes, nous utilisons le nom de la classe en minuscule, en remplaçant les
occurrences de @code{.} par des tirets et en préfixant le tout par
@code{java-}.  Donc la classe @code{apache.commons.cli} devient
@code{java-apache-commons-cli}.


@node Paquets Rust
@subsection Paquets Rust

@cindex rust
Le programmes Rust utiles en soit sont nommés comme les autres paquets, avec
le nom amont en minuscule.

Pour éviter des collisions de noms nous préfixons les autres paquets avec le
préfixe @code{rust-}.  Vous devrez changer le nom en minuscule et garder les
tirets en place.

Dans l'écosystème rust il est courant d'avoir plusieurs versions
incompatibles d'un paquet utilisées en même temps, donc toutes les
définitions des paquets devraient avoir un suffixe de version. Le suffixe de
version est le nombre le plus à gauche qui n'est pas un zéro (et tous les
zéros précédents, évidemment). Cela suit les conventions de version « caret
» de Cargo. Par exemple @code{rust-clap-2}, @code{rust-rand-0.6}.

À cause de la difficulté à réutiliser des paquets rust en entrées
précompilées pour d'autres paquets, le systèmes de construction Cargo
(@pxref{Systèmes de construction, @code{cargo-build-system}}) présente les mots-clefs
@code{#:cargo-inputs} et @code{cargo-development-inputs} en argument du
système de construction.  Vous pouvez y penser comme les équivalents de
@code{propagated-inputs} et @code{native-inputs}.  Les @code{dependencies}
et @code{build-dependencies} de Rust devraient aller dans
@code{#:cargo-inputs} et @code{dev-dependencies} dans
@code{#:cargo-development-inputs}.  Si un paquet Rust se lie à d'autres
bibliothèques alors vous devriez utiliser l'emplacement @code{inputs}
standard et compagnie.

Vous devriez faire attention à vous assurer que la bonne version des
dépendances est utilisée ; pour cela nous essayons d'éviter de passer les
tests ou d'utiliser @code{#:skip-build?} lorsque c'est possible.  Bien sûr
ce n'est pas toujours possible, comme le paquet peut être développé sur un
autre système d'exploitation, dépendre d'une fonctionnalité du compilateur
Rust Nightly ou la suite de test atrophiée depuis la sortie.


@node Paquets elm
@subsection Paquets elm

@cindex Elm
Les applications Elm peuvent être nommée comme les autres logiciels : leur
nom n'a pas besoin de mentionner Elm.

Les paquets au sens de Elm (voir @code{elm-build-system} dans @ref{Systèmes de construction}) doivent utiliser un nom au format
@var{auteur}@code{/}@var{projet}, où à la fois l'@var{auteur} et le
@var{projet} peuvent contenir des tirets, et @var{auteur} contient parfois
des lettres majuscules.

Pour former le nom de paquet Guix à partir du nom en amont, nous suivons une
convention similaire à celle des paquets Python (@pxref{Modules Python}), en
ajoutant le préfixe @code{elm-} à moins que le nom ne commence déjà par
@code{elm-}.

Dans la plupart des cas on peut reconstruire le nom d'un paquet Elm en amont
avec une heuristique, mais, comme la conversion vers le nom Guix implique
une perte d'information, cela n'est pas toujours possible. Vous devrez faire
attention à ajouter la propriété @code{'upstream-name} si nécessaire pour
que @samp{guix import elm} fonctionne correctement (@pxref{Invoquer guix import}). Les scénarios les plus importants où il faut spécifier
explicitement le nom en amont sont :

@enumerate
@item
Lorsque l'@var{auteur} est @code{elm} et que le @var{projet} contient une ou
plusieurs tirets, comme @code{elm/virtual-dom} et

@item
Lorsque l'@var{auteur} contient des tirets ou des lettres majuscule, comme
@code{Elm-Canvas/raster-shapes} --- à moins que l'@var{auteur} ne soit
@code{elm-explorations}, qui est géré à part, donc un paquet comme
@code{elm-explorations/markdown} n'a @emph{pas} besoin d'utiliser la
propriété @code{'upstream-name}.
@end enumerate

Le module @code{(guix build-system elm)} fournit les utilitaires suivants
pour travailler avec les noms et les conventions associées :

@deffn {Procédure Scheme} elm-package-origin @var{elm-name} @var{version} @
  @var{hash}
Renvoie une origine Git en utilisant le nom et les tags du dépôts, requis
pour publier un paquet Elm avec le nom amont @var{elm-name} à la version
@var{version} avec la somme de contrôle sha256 @var{hash}.

Par exemple :
@lisp
(package
  (name "elm-html")
  (version "1.0.0")
  (source
   (elm-package-origin
    "elm/html"
    version
    (base32 "15k1679ja57vvlpinpv06znmrxy09lbhzfkzdc89i01qa8c4gb4a")))
  ...)
@end lisp
@end deffn

@deffn {Procédure Scheme} elm->package-name @var{elm-name}
Renvoie le nom de paquet Guix pour un paquet Elm avec le nom amont
@var{elm-name}.

Remarquez qu'il y a plus d'un @var{elm-name} possible pour un résultat de
@code{elm->package-name} donné.
@end deffn

@deffn {Procédure Scheme} guix-package->elm-name @var{paquet}
Étant donné un @var{paquet} Elm, renvoie le nom amont éventuellement inféré,
ou @code{#f} si le nom amont n'est pas spécifié via la propriété
@code{'upstream-name} et qu'il ne peut pas être deviné par
@code{infer-elm-package-name}.
@end deffn

@deffn {Procédure Scheme} inferior-elm-package-name @var{guix-name}
Étant donné le @var{guix-name} d'un paquet Elm, renvoie le nom amont inféré,
ou @code{#f} si le nom amont ne peut pas être inféré. Si le résultat n'est
pas @code{#f}, l'envoyer à @code{elm->package-name} produirait
@var{guix-name}.
@end deffn

@node Polices de caractères
@subsection Polices de caractères

@cindex polices
Pour les polices qui ne sont en général pas installées pour être utilisées
pour du traitement de texte, ou qui sont distribuées en tant que partie d'un
paquet logiciel plus gros, nous nous appuyons sur les règles générales pour
les logiciels ; par exemple, cela s'applique aux polices livrées avec le
système X.Org ou les polices qui font partie de TeX Live.

Pour rendre plus facile la recherche par l'utilisatrice ou l'utilisateur,
les noms des autres paquets contenant seulement des polices sont construits
ainsi, indépendamment du nom du paquet en amont.

Le nom d'un paquet contenant une unique famille de polices commence par
@code{font-} ; il est suivi du nom du fondeur et d'un tiret @code{-} si le
fondeur est connu, et du nom de la police, dont les espaces sont remplacés
par des tirets (et comme d'habitude, toutes les lettres majuscules sont
transformées en minuscules).  Par exemple, la famille de polices Gentium de
SIL est empaqueté sous le nom @code{font-sil-gentium}.

Pour un paquet contenant plusieurs familles de polices, le nom de la
collection est utilisée à la place du nom de la famille.  Par exemple les
polices Liberation consistent en trois familles, Liberation Sans, Liberation
Serif et Liberation Mono.  Elles pourraient être empaquetées séparément sous
les noms @code{font-liberation-sans} etc, mais comme elles sont distribuées
ensemble sous un nom commun, nous préférons les empaqueter ensemble en tant
que @code{font-liberation}.

Dans le cas où plusieurs formats de la même famille ou collection sont
empaquetés séparément, une forme courte du format, préfixé d'un tiret est
ajouté au nom du paquet.  Nous utilisont @code{-ttf} pour les polices
TrueType, @code{-otf} pour les polices OpenType et @code{-type1} pour les
polices Type 1 de PostScript.


@node Style de code
@section Style de code

En général notre code suit le Standard de Code GNU (@pxref{Top,,, standards,
GNU Coding Standards}).  Cependant, il ne parle pas beaucoup de Scheme, donc
voici quelques règles supplémentaires.

@menu
* Paradigme de programmation::  Comment composer vos éléments.
* Modules::                  Où stocker votre code ?
* Types de données et reconnaissance de motif::  Implémenter des 
                                                    structures de données.
* Formatage du code::        Conventions d'écriture.
@end menu

@node Paradigme de programmation
@subsection Paradigme de programmation

Le code Scheme dans Guix est écrit dans un style purement fonctionnel.  Le
code qui s'occupe des entrées-sorties est une exception ainsi que les
procédures qui implémentent des concepts bas-niveau comme la procédure
@code{memoize}.

@node Modules
@subsection Modules

Les modules Guile qui sont sensés être utilisés du côté de la construction
doivent se trouver dans l'espace de nom @code{(guix build @dots{})}.  Ils ne
doivent pas se référer à d'autres modules Guix ou GNU@.  Cependant il est
correct pour un module « côté hôte » de dépendre d'un module coté
construction.

Les modules qui s'occupent du système GNU général devraient se trouver dans
l'espace de nom @code{(gnu @dots{})} plutôt que @code{(guix @dots{})}.

@node Types de données et reconnaissance de motif
@subsection Types de données et reconnaissance de motif

La tendance en Lisp classique est d'utiliser des listes pour tout
représenter et de naviguer dedans « à la main ( avec @code{car}, @code{cdr},
@code{cadr} et compagnie.  Il y a plusieurs problèmes avec ce style,
notamment le fait qu'il soit dur à lire, source d'erreur et un obstacle aux
rapports d'erreur bien typés.

Guix code should define appropriate data types (for instance, using
@code{define-record-type*}) rather than abuse lists.  In addition, it should
use pattern matching, via Guile’s @code{(ice-9 match)} module, especially
when matching lists (@pxref{Pattern Matching,,, guile, GNU Guile Reference
Manual}).

@node Formatage du code
@subsection Formatage du code

@cindex formater le code
@cindex style de code
Lorsque nous écrivons du code Scheme, nous suivons la sagesse commune aux
programmeurs Scheme.  En général, nous suivons les
@url{https://mumble.net/~campbell/scheme/style.txt, règles de style de
Riastradh}.  Ce document décrit aussi les conventions utilisées dans le code
de Guile.  Il est bien pensé et bien écrit, alors n'hésitez pas à le lire.

Certaines formes spéciales introduites dans Guix comme la macro
@code{substitute*} ont des règles d'indentation spécifiques.  Elles sont
définies dans le fichier @file{.dir-locals.el} qu'Emacs utilise
automatiquement.  Remarquez aussi qu'Emacs-Guix fournit le mode
@code{guix-devel-mode} qui indente et colore le code Guix correctement
(@pxref{Développement,,, emacs-guix, The Emacs-Guix Reference Manual}).

@cindex indentation, du code
@cindex formatage, du code
Si vous n'utilisez pas Emacs, assurez-vous que votre éditeur connaisse ces
règles.  Pour indenter automatiquement une définition de paquet, vous pouvez
aussi lancer :

@example
./pre-inst-env guix style @var{paquet}
@end example

@noindent
@xref{Invoquer guix style}, pour plus d'informations.

@cindex Vim, édition de code Scheme
Si vous éditez du code avec Vim, nous recommandons de lancer @code{:set
autoindent} pour que votre code soit automatiquement indenté au moment où
vous l'entrez.  En plus,
@uref{https://www.vim.org/scripts/script.php?script_id=3998,
@code{paredit.vim}} peut vous aider à gérer toutes ces parenthèses.

Nous demandons que toutes les procédure de premier niveau contiennent une
chaîne de documentation.  Ce prérequis peut être relâché pour les procédures
privées simples dans l'espace de nom @code{(guix build @dots{})} cependant.

Les procédures ne devraient pas avoir plus de quatre paramètres
positionnés. Utilisez des paramètres nommés pour les procédures qui prennent
plus de quatre paramètres.


@node Envoyer des correctifs
@section Envoyer des correctifs

Le développement se fait avec le système de contrôle de version Git.  Ainsi,
l'accès au dépôt n'est pas strictement nécessaire.  Nous accueillons les
contributions sous forme de correctifs produits par @code{git format-patch}
envoyés sur la liste de diffusion @email{guix-patches@@gnu.org}
(@pxref{Submitting patches to a project,,, git, Git User Manual}). Si vous
voulez contribuer, nous vous encourageons à prendre un moment pour changer
quelques options du dépôt Git pour améliorer la lisibilité des correctifs
avant de commencer (@pxref{Configurer Git}). Si vous avez bien expérimenté
la contribution à Guix, vous pouvez aussi regarder la section sur les accès
en commit (@pxref{Accès en commit}).

Cette liste de diffusion est gérée par une instance Debbugs, qui nous permet
de suivre les soumissions.  Chaque message envoyé à cette liste se voit
attribuer un nouveau numéro de suivi ; les gens peuvent ensuite répondre à
cette soumission en envoyant un courriel à
@code{@var{NUMÉRO_PROBLÈME}@@debbugs.gnu.org}, où @var{NUMÉRO_PROBLÈME} est
le numéro de suivi (@pxref{Envoyer une série de correctifs}).

Veuillez écrire les messages de commit dans le format ChangeLog
(@pxref{Change Logs,,, standards, GNU Coding Standards}) ; vous pouvez
regarder l'historique des commits pour trouver des exemples.

Avant de soumettre un correctif qui ajoute ou modifie la définition d'un
paquet, veuillez vérifier cette check-list :

@enumerate
@item
Si les auteurs ou autrices du paquet logiciel fournissent une signature
cryptographique pour l'archive, faites un effort pour vérifier
l'authenticité de l'archive.  Pour un fichier de signature GPG détaché, cela
se fait avec la commande @code{gpg --verify}.

@item
Prenez un peu de temps pour fournir un synopsis et une description adéquats
pour le paquet.  @xref{Synopsis et descriptions} pour quelques lignes
directrices.

@item
Lancez @code{guix lint @var{paquet}}, où @var{paquet} est le nom du nouveau
paquet ou du paquet modifié, et corrigez les erreurs qu'il rapporte
(@pxref{Invoquer guix lint}).

@item
Lancez @code{guix style @var{paquet}} pour formater la nouvelle définition
du paquet en suivant les conventions du projet (@pxref{Invoquer guix style}).

@item
Assurez-vous que le paquet se construise sur votre plate-forme avec
@code{guix build @var{paquet}}.

@item
Nous vous recommandons aussi d'essayer de construire le paquet sur les
autres plate-formes prises en charge.  Comme vous n'avez pas forcément accès
aux plate-formes matérielles, nous vous recommandons d'utiliser le
@code{qemu-binfmt-service-type} pour les émuler.  Pour cela, ajoutez le
module de service @code{virtualization} et le service suivant à la liste des
services dans votre configuration de système d'exploitation :

@lisp
(service qemu-binfmt-service-type
 (qemu-binfmt-configuration
   (platforms (lookup-qemu-platforms "arm" "aarch64"))))
@end lisp

Puis reconfigurez votre système.

Vous pourrez ensuite construire les paquets pour différentes plate-formes en
spécifiant l'option @code{--system}.  Par exemple pour construire le paquet
« hello » pour les architectures armhf ou aarch64, vous devrez lancer les
commandes suivantes, respectivement :
@example
guix build --system=armhf-linux --rounds=2 hello
guix build --system=aarch64-linux --rounds=2 hello
@end example

@item
@cindex construction groupée
Assurez-vous que le paquet n'utilise pas de copie groupée d'un logiciel déjà
disponible dans un paquet séparé.

Parfois, les paquets incluent des copie du code source de leurs dépendances
pour le confort des utilisateur·rices.  Cependant, en tant que distribution,
nous voulons nous assurer que ces paquets utilisent bien les copient que
nous avons déjà dans la distribution si elles existent.  Cela améliore
l'utilisation des ressources (la dépendance n'est construite et stockée
qu'une seule fois) et permet à la distribution de faire des changements
transversaux comme appliquer des correctifs de sécurité pour un paquet donné
depuis un unique emplacement et qu'ils affectent tout le système, ce
qu'empêchent les copies groupées.

@item
Regardez le profil rapporté par @command{guix size} (@pxref{Invoquer guix size}).  Cela vous permettra de remarquer des références à d'autres paquets
qui ont été retenus sans que vous vous y attendiez.  Il peut aussi aider à
déterminer s'il faut découper le paquet (@pxref{Des paquets avec plusieurs résultats}) et quelles dépendances facultatives utiliser.  En particulier,
évitez d'ajouter @code{texlive} en dépendance : à cause de sa taille
extrême, utilisez @code{texlive-tiny} ou @code{texlive-union} à la place.

@item
Pour les changements important, vérifiez que les paquets qui en dépendent
(s'ils existent) ne sont pas affectés par le changement ; @code{guix refresh
--list-dependant @var{paquet}} vous aidera (@pxref{Invoquer guix refresh}).

@c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
@cindex stratégie de branche
@cindex stratégie de planification des reconstructions
Suivant le nombre de paquets dépendants et donc le nombre de reconstruction
induites, les commits vont vers des branches différentes, suivant ces
principes :

@table @asis
@item 300 paquets dépendants ou moins
branche @code{master} (changements non-disruptifs).

@item entre 300 et 1 800 paquets dépendants
branche @code{staging} (changements non-disruptifs).  Cette branche devrait
être fusionnées dans @code{master} toutes les 6 semaines.  Les changements
par thèmes (par exemple une mise à jour de la pile GNOME) peuvent aller dans
une branche spécifique (disons, @code{gnome-updates}). Il n'est pas
forcément possible de construire ni utiliser cette branche jusque tard dans
le processus de développement.

@item plus de 1 800 paquets dépendants
la branche @code{core-updates} (peut inclure des changements majeurs et
potentiellement disruptifs).  Cette branche devrait être fusionnée dans
@code{master} tous les 6 mois environ. Il n'est pas forcément possible de
construire ni utiliser cette branche jusque tard dans le processus de
développement.
@end table

Toutes ces branches sont @uref{https://@value{SUBSTITUTE-SERVER-1}, gérées
par notre ferme de construction} et fusionnées dans @code{master} une fois
que tout a été construit correctement.  Cela nous permet de corriger des
problèmes avant qu'ils n'atteignent les utilisateur·rices et réduit la
fenêtre pendant laquelle les binaires pré-construits ne sont pas
disponibles.

@c TODO: It would be good with badges on the website that tracks these
@c branches.  Or maybe even a status page.
Lorsqu'on décide de commencer à construire la branche @code{staging} ou
@code{core-updates}, on les fork et on les renomme avec le suffixe
@code{-frozen}, et à partir de ce moment, seuls les corrections de bogues
sont poussées sur les branches gelées. Les branches @code{core-updates} et
@code{staging} restent ouvertes et acceptent des correctifs pour le prochain
cycle. Demandez sur la liste de diffusion ou sur IRC si vous ne savez pas où
envoyer un correctif.

@item
@cindex déterminisme, du processus de construction
@cindex construction reproductibles, vérification
Vérifiez si le processus de construction du paquet est déterministe.  Cela
signifie typiquement vérifier qu'une construction indépendante du paquet
renvoie exactement le même résultat que vous avez obtenu, bit à bit.

Une manière simple de le faire est de reconstruire le paquet plusieurs fois
à la suite sur votre machine (@pxref{Invoquer guix build}) :

@example
guix build --rounds=2 mon-paquet
@end example

Cela est suffisant pour trouver une classe de non-déterminisme commune,
comme l'horodatage ou des sorties générées aléatoirement dans le résultat de
la construction.

Une autre option consiste à utiliser @command{guix challenge}
(@pxref{Invoquer guix challenge}).  Vous pouvez lancer la commande une fois
que les paquets ont été committés et construits par
@code{@value{SUBSTITUTE-SERVER-1}} pour vérifier s'il obtient le même
résultat que vous.  Mieux encore : trouvez une autre machine qui peut le
construire et lancez @command{guix publish}.  Puisque la machine distante
est sûrement différente de la vôtre, cela peut trouver des problèmes de
non-déterminisme liés au matériel — par exemple utiliser une extension du
jeu d'instruction — ou du noyau du système d'exploitation — par exemple se
reposer sur @code{uname} ou les fichiers de @file{/proc}.

@item
Lorsque vous écrivez de la documentation, utilisez une formulation au genre
neutre lorsque vous vous référez à des personnes, comme le
@uref{https://fr.wikipedia.org/wiki/They_singulier, ``they''@comma{}
``their''@comma{} ``them'' singulier} (en anglais).

@item
Vérifiez que votre correctif contienne seulement un ensemble de changements
liés.  Grouper des changements non liés ensemble rend la revue plus
difficile et plus lente.

Ajouter plusieurs paquet ou une mise à jour d'un paquet avec des corrections
dans ce paquet sont des exemples de changements sans rapport.

@item
Suivez nos règles de formatage de code, éventuellement en lançant le script
@command{guix style} pour le faire automatiquement (@pxref{Formatage du code}).

@item
Si possible, utilisez des miroirs dans l'URL des sources (@pxref{Invoquer guix download}).  Utilisez des URL stable, pas des URL générées.  Par
exemple, les archives GitHub ne sont pas nécessairement identiques d'une
génération à la suivante, donc il vaut mieux dans ce cas cloner le dépôt.
N'utilisez pas le champ @command{name} dans l'URL : ce n'est pas très utile
et si le nom change, l'URL sera probablement erronée.

@item
Vérifiez si Guix compile (@pxref{Construire depuis Git}) et corrigez les
avertissements, surtout ceux à propos de symboles manquants.

@item
Assurez-vous que vos changements ne cassent pas Guix et simulez un
@code{guix pull} avec :
@example
guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master
@end example

@end enumerate

Lorsque vous envoyez un correctif à la liste de diffusion, utilisez
@samp{[PATCH] @dots{}} comme objet. Si votre correctif doit être appliqué à
une autre branche que @code{master}, comme @code{core-updates}, spécifiez-le
dans l'objet comme dans @samp{[PATCH core-updates] @dots{}}.

Vous pouvez utiliser votre client de messagerie ou la commande @command{git
send-email} (@pxref{Envoyer une série de correctifs}). Nous préférons recevoir les
correctifs dans des messages en texte clair, soit en ligne, soit sous forme
de pièces jointes MIME.  Il vous est conseillé de faire attention si votre
client de messagerie modifie quoi que ce soit, comme des sauts de ligne ou
des indentations, qui pourraient potentiellement casser les correctifs.

Attendez-vous à un délai entre le moment où vous envoyez votre tout premier
correctif à @email{guix-patches@@gnu.org} et le moment où le message sera
reçu. Vous devez attendre de recevoir un message de confirmation avec le
numéro de suivi assigné à votre correctif. Les confirmations suivantes ne
seront pas retardées.

Lorsqu'un bogue est résolu, veuillez fermer le fil en envoyant un courriel à
@email{@var{NUMÉRO_PROBLÈME}-done@@debbugs.gnu.org}.

@node Configurer Git
@subsection Configurer Git
@cindex configuration git
@cindex @code{git format-patch}
@cindex @code{git send-email}

Si vous ne l'avez pas encore fait, vous devriez indiquer un nom et une
adresse de courriel qui seront associés à vos commits (@pxref{telling git your name, , Telling Git your name, git, Git User Manual}). Si vous
souhaitez utiliser un nom ou une adresse différent pour les commits de ce
dépôt, vous pouvez utiliser @command{git config --local}, ou modifier
@file{.git/config} dans le dépôt au lieu de @file{~/.gitconfig}.

Nous fournissons quelques paramètres par défaut dans
@file{etc/git/gitconfig} qui modifient la manière de générer des correctifs,
pour les rendre plus lisibles et plus faciles à appliquer. Vous pouvez
appliquer ces paramètres manuellement en les copiant dans @file{.git/config}
dans votre dépôt, ou en disant à Git d'inclure le fichier complet :

@example
git config --local include.path ../etc/git/gitconfig
@end example

À partir de maintenant, tout changement de @file{etc/git/gitconfig} prendra
automatiquement effet.

Comme le premier correctif d'une série doit être envoyé séparément
(@pxref{Envoyer une série de correctifs}), il peut être intéressant de dire à
@command{git format-patch} de se charger de la création d'un fil de
discussion à la place de @command{git send-email} :

@example
git config --local format.thread shallow
git config --local sendemail.thread no
@end example

@node Envoyer une série de correctifs
@subsection Envoyer une série de correctifs
@cindex série de correctifs
@cindex @code{git send-email}
@cindex @code{git format-patch}

@unnumberedsubsubsec Correctifs isolés
@anchor{Correctifs isolés}
La commande @command{git send-email} est la meilleure manière d'envoyer
aussi bien des correctifs isolés que des séries de correctifs
(@pxref{Plusieurs correctifs}) à la liste de diffusion de Guix. Envoyer des
correctifs en pièce-jointe peut les rendre plus difficile à revoir dans
certains clients de courriel et @command{git diff} ne stocke pas les
métadonnées des commits.

@quotation Remarque
La commande @command{git send-email} est fournie par la sortie
@code{send-email} du paquet @code{git}, c.-à-d.@: @code{git:send-email}.
@end quotation

La commande suivante créera un courriel de correctif à partir du dernier
commit, l'ouvrira dans @var{EDITOR} ou @var{VISUAL} pour que vous puissiez
le modifier et l'enverra à la liste de diffusion de Guix pour qu'il soit
revu et fusionné :

@example
$ git send-email -1 -a --base=auto --to=guix-patches@@gnu.org
@end example

@quotation Astuce
Pour ajouter un préfixe à l'objet de votre correctif, vous pouvez utiliser
l'option @option{--subject-prefix}. Le projet Guix utilise cela pour
spécifier si un correctif est prévu pour une autre branche ou un autre dépôt
que la branche @code{master} de
@url{https://git.savannah.gnu.org/cgit/guix.git}.

@example
git send-email -1 -a --base=auto \
    --subject-prefix='PATCH core-updates' \
    --to=guix-patches@@gnu.org
@end example
@end quotation

Le courriel de correctif contient une ligne de séparation à trois tirets
après le message de commit. Vous pouvez « annoter » le correctif avec un
texte explicatif en l'ajoutant sous cette ligne. Si vous ne voulez pas
annoter le courriel, vous pouvez enlever le drapeau @option{-a} (qui est le
raccourci pour @option{--annotate}).

Le drapeau @option{--base=auto} ajoute automatiquement une note à la fin du
correctif indiquant le commit sur lequel il est basé, ce qui facilite le
rebasage et la fusion de votre correctif pour les mainteneurs.

Si vous voulez envoyer un correctif modifié, ne le renvoyez pas de cette
manière et n'envoyez pas un correctif de « correction » à appliquer sur
l'ancien ; à la place, utilisez @command{git commit -a} ou
@url{https://git-rebase.io, @command{git rebase}} pour modifier le commit,
et utilisez l'adresse @email{@var{NUMÉRO_PROBLÈME}@@debbugs.gnu.org} et le
drapeau @option{-v} avec @command{git send-email}.

@example
$ git commit -a
$ git send-email -1 -a --base=auto -v @var{RÉVISION} \
      --to=@var{NUMÉRO_PROBLÈME}@@debbugs.gnu.org
@end example

Vous pouvez trouver @var{NUMÉRO_PROBLÈME} soit en cherchant sur l'interface
mumi sur @url{issues.guix.gnu.org} le nom de votre correctif ou en lisant
l'accusé de réception envoyé automatiquement par Debbugs en réponse aux
bogues et correctifs entrants, qui contient le numéro de suivi.

@unnumberedsubsubsec Notifier les équipes
@anchor{Notifier les équipes}
@cindex équipes
Le script @file{etc/teams.scm} peut être utilisé pour notifier toutes les
personnes qui sont intéressées par votre correctif (@pxref{Équipes}). Utilisez
@command{etc/teams.scm list-teams} pour afficher toutes les équipes, pour
décider quelles équipes votre correctif intéressera et utilisez
@command{etc/teams.scm cc} pour afficher les drapeaux @command{git
send-email} qui notifieront les membres des équipes appropriées ou utilisez
@command{etc/teams.scm cc-members} pour automatiquement détecter les équipes
appropriées.

@unnumberedsubsubsec Plusieurs correctifs
@anchor{Plusieurs correctifs}
@cindex résumé
Alors que @command{git send-email} seul suffira pour un unique correctif, un
problème malheureux de Debbugs fait que vous devrez faire plus attention
pour envoyer plusieurs correctifs : si vous les envoyez tous à l'adresse
@email{guix-patches@@gnu.org}, un nouveau ticket sera créé pour chaque
correctif !

Lorsque vous envoyez une série de correctifs, il vaut mieux envoyer d'abord
un « résumé » Git pour donner un aperçu de votre série de correctifs aux
relecteur·ices. Vous pouvez créer un répertoire nommé @file{sortant}
contenant à la fois votre série de correctifs et un résumé appelé
@file{0000-cover-letter.patch} avec @command{git format-patch}.

@example
$ git format-patch -@var{NOMBRE_COMMITS} -o sortant \
      --cover-letter --base=auto
@end example

Vous pouvez maintenant envoyer @emph{seulement} le résumé à l'adresse
@email{guix-patches@@gnu.org} ce qui créera un ticket auquel vous pourrez
envoyer le reste des correctifs.

@example
$ git send-email outgoing/0000-cover-letter.patch -a \
      --to=guix-patches@@debbugs.gnu.org \
      $(etc/teams.scm cc-members ...)
$ rm sortant/0000-cover-letter.patch # on ne veut pas le renvoyer !
@end example

Assurez-vous de modifier le courriel pour ajouter une ligne d'objet
appropriée et un petit texte avant de l'envoyer. Remarquez le journal court
et les statistiques de changements générés automatiquement sous votre texte.

Une fois que le logiciel de Debbugs a répondu à votre courriel de résumé,
vous pouvez envoyer les correctifs à l'adresse de suivi nouvellement créée.

@example
$ git send-email sortant/*.patch \
      --to=@var{NUMÉRO_PROBLÈME}@@debbugs.gnu.org \
      $(etc/teams.scm cc-members ...)
$ rm -rf sortant # on n'en a plus besoin
@end example

Heureusement, cette danse avec @command{git format-patch} n'est pas
nécessaire pour envoyer une série modifiée car un ticket existe déjà pour la
suite de correctifs.

@example
$ git send-email -@var{NOMBRE_COMMITS} \
      -v@var{RÉVISION} --base=auto \
      --to @var{NUMÉRO_PROBLÈME}@@debbugs.gnu.org
@end example

Si besoin, vous pouvez utiliser @option{--cover-letter -a} pour envoyer un
autre résumé, p.@: ex.@: pour expliquer ce qui a changé par rapport à
l'ancienne révision et que ces changements sont nécessaires.

@node Équipes
@subsection Équipes
@cindex équipes

Il y a plusieurs équipes qui prennent en charge différentes parties du code
source de Guix. Pour lister toutes ces équipes, vous pouvez exécuter depuis
un clone de Guix :

@example
$ ./etc/teams.scm list-teams
id: mentors
name: Mentors
description: A group of mentors who chaperone contributions by newcomers.
members:
+ Christopher Baines <mail@@cbaines.net>
+ Ricardo Wurmus <rekado@@elephly.net>
+ Mathieu Othacehe <othacehe@@gnu.org>
+ jgart <jgart@@dismail.de>
+ Ludovic Courtès <ludo@@gnu.org>
@dots{}
@end example

Vous pouvez exécuter la commande suivante pour ajouter l'équipe
@code{Mentors} en CC de votre série de correctifs :

@example
$ git send-email --to @var{NUMÉRO_PROBLÈME}@@debbugs.gnu.org $(./etc/teams.scm cc mentors) *.patch
@end example

L'équipe ou les équipes appropriées peuvent aussi être inférées à partir des
fichiers modifiés. Par exemple, si vous voulez envoyer les deux derniers
commits du dépôt Git actuel à la revue, vous pouvez exécuter :

@example
$ guix shell -D guix
[env]$ git send-email --to @var{NUMÉRO_PROBLÈME}@@debbugs.gnu.org $(./etc/teams.scm cc-members HEAD~2 HEAD) *.patch
@end example

@node Suivi des bogues et des correctifs
@section Suivi des bogues et des correctifs

Cette section décrit comme le projet Guix suit les rapports de bogues et les
soumissions de correctifs.

@menu
* L'outil de gestion des défauts::  L'outil de gestion des bogues et des 
                                       correctifs officiel.
* Interfaces utilisateurs à Debbugs::  Plusieurs manières d'interagir avec 
                                          Debbugs.
* Étiquettes personnalisées de Debbugs::  Étiqueter les rapports avec des 
                                              étiquettes personnalisées.
@end menu

@node L'outil de gestion des défauts
@subsection L'outil de gestion des défauts

@cindex rapports de bogue, suivi
@cindex soumission de correctifs, suivi
@cindex suivi de tickets
@cindex Debbugs, système de suivi de tickets
Les rapports de bogue et les correctifs soumis sont actuellement suivis par
l'instance Debbugs @uref{https://bugs.gnu.org}.  Les rapports de bogue sont
rempli pour le « paquet » @code{guix} (dans le vocabulaire de Debbugs), en
envoyant un courriel à @email{bug-guix@@gnu.org}, tandis que les correctifs
sont soumis pour le paquet @code{guix-patches} en envoyant un courriel à
@email{guix-patches@@gnu.org} (@pxref{Envoyer des correctifs}).

@node Interfaces utilisateurs à Debbugs
@subsection Interfaces utilisateurs à Debbugs

Une interface web (en fait @emph{deux} interfaces web !) sont disponibles
pour naviguer dans les tickets :

@itemize
@item
@url{https://issues.guix.gnu.org} fournit une interface
agréable@footnote{L'interface web à @url{https://issues.guix.gnu.org} est
alimentée par Mumi, un logiciel très cool écrit en Guile, votre aide est la
bienvenue ! Voir
@url{https://git.elephly.net/gitweb.cgi?p=software/mumi.git}.} pour
consulter les rapports de bogues et les correctifs, et pour participer aux
discussions ;
@item
@url{https://bugs.gnu.org/guix} liste les rapports de bogues ;
@item
@url{https://bugs.gnu.org/guix-patches} liste les tickets soumis.
@end itemize

Pour consulter les discussions relatives au numéro d'édition @var{n},
rendez-vous sur @indicateurl{https://issues.guix.gnu.org/@var{n}} ou
@indicateurl{https://bugs.gnu.org/@var{n}}.

Si vous utilisez Emacs, vous pourriez trouver plus confortable d'interagir
avec les tickets en utilisant @file{debbugs.el}, que vous pouvez installer
avec :

@example
guix install emacs-debbugs
@end example

Par exemple, pour lister tous les tickets ouverts sur @code{guix-patches},
tapez :

@example
@kbd{C-u} @kbd{M-x} debbugs-gnu @kbd{RET} @kbd{RET} guix-patches @kbd{RET} n y
@end example

@xref{Top,,, debbugs-ug, Debbugs User Guide}, pour plus d'info sur cet outil
pratique !

@node Étiquettes personnalisées de Debbugs
@subsection Étiquettes personnalisées de Debbugs

@cindex étiquettes personnalisées, pour debbugs
@cindex Étiquettes personnalisées pour Debbugs
Debbugs fournit une fonctionnalité nommée @dfn{étiquettes personnalisées}
(usertags) qui permettent à tous d’étiqueter un bogue avec une étiquette
arbitraire. On peut rechercher les bogues par étiquette, ce qui les rend
pratiques pour organiser les bogues@footnote{La liste des étiquettes
personnalisées est publique, et n'importe qui peut modifier la liste des
étiquettes de n'importe qui, donc pensez-y si vous utilisez cette
fonctionnalité.}.

Par exemple, pour voir tous les rapports de bogues (ou les correctifs, dans
le cas de @code{guix-patches} avec l'étiquette personnalisée
@code{powerpc64le-linux} pour l'utilisateur @code{guix}, ouvrez cette URL
dans un navigateur web :
@url{https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix}.

Pour plus d'informations sur le fonctionnement des étiquettes
personnalisées, référez-vous à la documentation de Debbugs ou à la
documentation de n'importe quel outil que vous utilisez pour interagir avec
Debbugs.

Dans Guix, nous expérimentons les étiquettes personnalisées pour suivre les
problèmes spécifiques aux différentes architectures. Pour faciliter la
collaboration, toutes les étiquettes personnalisées sont associées à un
unique utilisateur @code{guix}. Les étiquettes suivantes existent pour cet
utilisateur :

@table @code

@item powerpc64le-linux
Le but de cet étiquettes est de faciliter la découverte des problèmes qui
sont les plus importants pour le type de système
@code{powerpc64le-linux}. Assignez cette étiquette aux bogues et aux
correctifs qui affectent @code{powerpc64le-linux} mais pas les autres types
de systèmes. En plus, vous pouvez l'utiliser pour identifier les problèmes
particulièrement importants pour le type de système
@code{powerpc64le-linux}, même si le problème affecte d'autres types de
systèmes aussi.

@item reproductibilité
Pour les problèmes de reproductibilité. Par exemple, ce serait approprié
d'assigner cette étiquette à un rapport de bogue pour un paquet qui ne se
construit pas de manière reproductible.

@end table

Si vous avez les droits en commit et que vous souhaitez ajouter une
étiquette personnalisée, utilisez-la simplement avec l'utilisateur
@code{guix}. Si l'étiquette vous est utile, vous pourrez alors mettre à jour
cette section du manuel pour que d'autres puissent savoir ce que votre
étiquette signifie.

@node Accès en commit
@section Accès en commit

@cindex accès en commit, pour les développeurs
Tout le monde peut contribuer à Guix même sans accès en commit
(@pxref{Envoyer des correctifs}). Cependant, pour les contributeurs et
contributrices fréquent·e·s, l'accès en écriture au dépôt peut être
pratique. Le principe général est qu'un contributeur ou une contributrice
devrait avoir accumulé cinquante commits revus pour demander les accès en
commit et il ou elle doit avoir eu une activité soutenue dans le projet
pendant au moins 6 mois. Cela permet de s'assurer qu'il y a eu suffisament
d'interactions avec le contributeur ou la contributrice, ce qui est
nécessaire pour accompagner la personne et évaluer si elle est prête à
recevoir les accès en commit. L'accès en commit n'est pas une médaille mais
plutôt une responsabilité qu'un contributeur ou une contributrice accepte
pour aider le projet.

Les sections suivantes expliquent comment recevoir des accès en commit,
comment se préparer à pousser des commits et la politique et les attentes de
la communauté pour les commits poussés en amont.

@subsection Candidater pour avoir accès en commit

Lorsque vous l'estimez nécessaire, pensez à candidater à l'accès en commit
en suivant les étapes suivantes :

@enumerate
@item
Trouvez trois personnes ayant les accès en commit et qui soutiendront votre
candidature.  Vous pouvez trouver la liste de ces personnes sur
@url{https://savannah.gnu.org/project/memberlist.php?group=guix}.  Chacune
d'entre elles devra envoyer une déclaration à
@email{guix-maintainers@@gnu.org} (un alias privé pour le collectif des
mainteneur·ses), signé de leur clef OpenPGP.

Les commiteurs devront avoir eu des interactions avec vous en tant que
contributeur et pouvoir juger si vous êtes suffisament familier avec les
pratiques du projet.  Ce n'est @emph{pas} un jugement sur la valeur de votre
travail, donc vous devriez plutôt interpréter un refus comme un « essayons
un peu plus tard ».

@item
Envoyez un message à @email{guix-maintainers@@gnu.org} déclarant votre
intention, listant les trois commiteur·ses qui supportent votre candidature,
signez-le avec la clef OpenPGP que vous utiliserez pour signer vos commits
et donnez son empreinte (voir plus bas).  Voir
@uref{https://emailselfdefense.fsf.org/fr/}, pour une introduction à la
cryptopgraphie à clef publique avec GnuPG.

@c See <https://sha-mbles.github.io/>.
Configurer GnuPG de manière à ce qu'il n'utilise jamais l'algorithme de
hachage SHA1 pour les signatures numériques, dont on sait qu'il est
dangereux depuis 2019, par exemple en ajoutant la ligne suivante à
@file{~/.gnupg/gpg.conf} (@pxref{GPG Esoteric Options, , , gnupg, The GNU
Privacy Guard Manual}) :

@example
digest-algo sha512
@end example

@item
Les mainteneur·ses ont le dernier mot sur la décision de vous donner accès
et suivent généralement l'avis de vos référents.

@item
@cindex OpenPGP, commits signés
Si vous obtenez l'accès, envoyez un message à @email{guix-devel@@gnu.org}
pour le faire savoir, en signant de nouveau avec le clef OpenPGP que vous
utiliserez pour signer les commits (faites-le avant votre premier commit).
De cette manière, tout le monde peut s'en rendre compte et s'assurer que
c'est bien vous qui contrôlez cette clef OpenPGP.

@quotation Important
Avant d'envoyer pour la première fois, les mainteneur·ses doivent :

@enumerate
@item
ajoutez votre clé OpenPGP à la branche @code{keyring} ;
@item
ajoutez votre empreinte OpenPGP au fichier @file{.guix-authorizations} de la
(des) branche(s) sur laquelle (lesquelles) vous vous engagez.
@end enumerate
@end quotation

@item
Assurez-vous de lire le reste de cette section et… profitez !
@end enumerate

@quotation Remarque
Les mainteneur·ses se réjouissent de donnéer l'accès en commit aux personnes
qui ont contribué depuis un certain temps et ont un historique — ne soyez
pas timide et ne sous-estimez pas votre travail !

Cependant, remarquez que le projet travail sur un système de revu de
correctifs et de fusion plus automatisé, qui, en conséquence, pourra nous
faire réduire le nombre de personne ayant accès en commit au dépôt
principal.  Restez à l'écoute !
@end quotation

Tous les commits poussés sur le dépôt central sur Savannah doivent être
signés avec une clef OpenPGP et la clef publique doit être chargée sur votre
compte utilisateur dans Savannah et les serveurs de clef publique, comme
@code{keys.opengpg.org}.  Pour configurer Git pour signer automatiquement
vos commits, lancez :

@example
git config commit.gpgsign true

# Remplacez l'empreinte par celle de votre clé PGP publique
git config user.signingkey CABBA6EA1DC0FF33
@end example

Pour vérifier que les commits sont signés avec une clé correcte, utilisez :

@example
make authenticate
@end example

Vous pouvez éviter de pousser accidentellement des commits non signés ou
signés avec une mauvaise clé vers Savannah et utilisant le crochet Git de
pré-envoi situé dans @file{etc/git/pre-push} :

@example
cp etc/git/pre-push .git/hooks/pre-push
@end example

II appelle aussi @code{make-check-channel-news} pour s'assurer que le
fichier @file{news.scm} est correct.

@subsection Politique de commit

Si vous avez accès en commit, assurez-vous de respecter la politique
ci-dessous (les discussions à propos de cette politique peuvent avoir lieu
sur @email{guix-devel@@gnu.org}).

Les correctifs non triviaux doivent toujours être postés sur
@email{guix-patches@@gnu.org} (les correctifs triviaux consistent en des
correctifs de coquilles, etc).  Cette liste de diffusion rempli la base de
données de correctifs (@pxref{Suivi des bogues et des correctifs}).

Pour les correctifs qui ne font qu'ajouter un nouveau paquet, et un paquet
simple, commiter directement est accepté si vous êtes en confiance (ce qui
signifie que vous avez réussi à le construire dans un environnement chroot
et avez fait un audit suffisant des copyrights et de la licence).  Pareil
pour les mises à jour de paquets, sauf pour les mises à jour qui
occasionnent beaucoup de reconstruction (par exemple mettre à jour GnuTLS ou
GLib).  Nous avons une liste de diffusion pour les notifications de commit
(@email{guix-commits@@gnu.org}), pour que les gens puissent s'en rendre
compte.  Avant de pousser vos changements, assurez-vous d'avoir lancé
@code{git pull --rebase}.

Lorsque vous poussez un commit pour le compte de quelqu'un d'autre, ajoutez
une ligne @code{Signed-off-by} à la fin du message de commit — p.@: ex.@:
avec @command{git am --signoff}.  Cela amélior le suivi que qui fait quoi.

Quand vous ajoutez de nouvelles entrées au canal (@pxref{Canaux, Writing
Channel News}), assurez-vous qu'elles sont bien formées en exécutant la
commande suivante juste avant d'envoyer :

@example
make check-channel-news
@end example

Pour tout autre chose, envoyez un correctif à @email{guix-patches@@gnu.org}
et laissez un peu de temps pour la revue, sans rien commiter
(@pxref{Envoyer des correctifs}).  Si vous ne recevez pas de réponse dans les
deux semaines et que vous avez confiance, vous pouvez commiter.

La dernière partie est sujète à ajustement, pour permettre à certains de
commiter directement des changements non controversés sur des parties qui
leurs sont familières.

@subsection Régler les problèmes

La revue par les pairs (@pxref{Envoyer des correctifs}) et les outils comme
@command{guix lint} (@pxref{Invoquer guix lint}) et la suite de tests
(@pxref{Lancer la suite de tests}) devraient trouver les problèmes avant
qu'ils ne soient poussés. Pourtant, il arrive parfois que des commits qui «
cassent » une fonctionnalité passent à travers les mailles du filet. Lorsque
cela arrive, il y a deux priorités : minimiser l'impact et comprendre ce qui
s'est passé, pour réduire les chances qu'un incident similaire se produise à
nouveau. Les personnes impliquées ont la plus grande part de responsabilité
dans ces deux tâches, mais comme pour tout le reste, c'est aussi un travail
commun.

Certains problèmes peuvent directement affecter les utilisateurs et
utilisatrices — par exemple si @command{guix pull} échoue ou qu'une
fonctionnalité importante est cassée parce que des paquets importants sont
cassés (à la construction ou à l'exécution), ou parce qu'ils introduisent
des problèmes de sécurités connus.

@cindex inverser des comits
Les personnes impliquées, auteurs, relecteurs et ayant poussé ces commits
devraient avant tout réduire leur impact rapidement en poussant un nouveau
commit qui le corrige (si c'est possible) ou en inversant les commits pour
laisser du temps avant de trouver un correctif satisfaisant, et en
communiquant le problème aux autres développeurs.

Si ces personnes ne peuvent pas s'occuper du problème à temps, les autres
commiteurs peuvent inverser les commits, en expliquant le problème dans le
message de commit et sur la liste de diffusion, dans le but de donner du
temps au commiteur, aux relecteurs et aux auteurs de proposer une solution.

Une fois que le problème a été réglé, il est de la responsabilité des
personnes impliquées de s'assurer que la situation a été comprise. Si vous
travaillez à comprendre ce qui est arrivé, efforcez-vous de récolter des
informations plutôt que de désigner des coupables. Demandez aux gens
impliqués de décrire ce qui est arrivé, ne leur demandez pas d'expliquer la
situation -- ce qui les mettrait implicitement dans une position de
responsabilité et n'est d'aucune aide. La responsabilité vient une fois
atteint un consensus sur le problème, qui permet d'apprendre de ce qui s'est
passé et d'améliorer les processus afin qu'il soit moins à risque de se
reproduire.

@subsection Révocation des droits en commit

Pour réduire la probabilité de faire une erreur, celles et ceux qui peuvent
commiter seront retiré·e·s du projet Guix sur Savannah et leur clé supprimée
de @file{.guix-authorizations} après 12 mois d'inactivité ; ils et elles
pourront retrouver leur accès en envoyant un courriel aux mainteneur·ses,
sans avoir à passer par le processus de cooptation.

Les mainteneur·ses@footnote{Voir @uref{https ://guix.gnu.org/fr/about} pour
la liste à jour des mainteneur·ses. Vous pouvez leur envoyer un courriel en
privé à l'adresse @email{guix-maintainers@@gnu.org}.} peuvent aussi révoquer
les droits en commit de quelqu'un, en dernier recours, si la coopération
avec le reste de la communauté a créé trop de friction -- même en restant
dans le cadre du code de conduite (@pxref{Contribuer}) du projet. Ils ne
le feraient qu'après une discussion publique ou privée avec la personne
concernée et un avertissement clair. Voici des exemples de comportements qui
gênent la coopération et pourraient mener à une telle décision :

@itemize
@item enfreindre de manière répétée la politique de commit indiquée ci-dessus ;
@item échouer de manière répétée à prendre en compte les critiques de la communauté ;
@item briser la confiance suite à une série d'incidents graves.
@end itemize

Quand les mainteneurs recourent à une telle décision, ils en informent les
développeurs sur @email{guix-devel@@gnu.org} ; des questions peuvent être
envoyées à @email{guix-maintainers@@gnu.org}. Suivant la situation, les
contributions de la personne peuvent rester bienvenues.

@subsection Aider

Une dernière chose : le projet continue à avancer non seulement parce que
les commiteurs poussent leurs propres changements, mais aussi parce qu'ils
offrent de leur temps pour @emph{revoir} et pousser les changements des
autres personnes.  En tant que commiteur, vous pouvez utiliser votre
expertise et vos droits en commit pour aider d'autres contributeaurs aussi !

@node Mettre à jour Guix
@section Mettre à jour Guix

@cindex update-guix-package, mise à jour du paquet guix
Il est quelquefois souhaitable de mettre à jour le paquet @code{guix}
lui-même (le paquet défini dans @code{(gnu packages package-management)}),
par exemple pour rendre de nouvelles caractéristiques disponibles à
l'utilisation par le type de service @code{guix-service-type}. Afin de
simplifier cette tâche, la commande suivante peut être utilisée :

@example
make update-guix-package
@end example

Le make target @code{update-guix-package} utilisera le dernier @emph{commit}
connu correspondant à @code{HEAD} dans votre checkout Guix, calculera le
hash des sources Guix correspondant à ce commit et mettra à jour la
définition des paquets @code{commit}, @code{revision} et le hash du paquet
@code{guix}.

Pour avoir la certitude que les hash du paquet @code{guix} mis à jour sont
corrects et qu'il peut être construit avec succès, la commande suivante peut
être lancée depuis le répertoire de votre checkout Guix :

@example
./pre-inst-env guix build guix
@end example

Pour éviter de mettre à jour accidentellement le paquet @code{guix} en un
commit auquel les autres ne peuvent pas se référer, on vérifie que le commit
utilisé a déjà été placé dans le dépôt git de Guix hébergé par Savannah.

Cette vérification peut être désactivée, @emph{à vos risques et périls}, en
passant la variable d'environnement
@code{GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT}.  Lorsque cette variable est
initialisée, les source du paquet mis à jour est aussi ajouté au dépôt.
Cela est utilisé dans le processus de publication de Guix.

@cindex documentation
@node Écrire de la documentation
@section Écrire de la documentation

Guix est documenté avec le système Texinfo. Si vous n'êtes pas à l'aise
avec, nous acceptons les contributions pour la documentation dans la plupart
des formats. Cela comprends le texte brut, Markdown, Org, etc.

Vous pouvez envoyer des contributions pour la documentation à
@email{guix-patches@@gnu.org}. Ajoutez @samp{[DOCUMENTATION]} au début de
l'objet.

Lorsque vous avez besoin de faire plus qu'un simple ajout à la
documentation, nous préférons que vous envoyiez un correctif plutôt que
d'envoyer un courriel comme précisé plus haut. @xref{Envoyer des correctifs}
pour en apprendre plus sur l'envoie de vos correctifs.

Pour modifier la documentation, vous devrez modifier @file{doc/guix.texi} et
@file{doc/contributing.texi} (qui contient cette section de la
documentation) ou @file{doc/guix-cookbook.texi} pour le livre de
recettes. Si vous avez déjà compilé le dépôt Guix, vous aurez bien plus de
fichiers @file{.texi} qui sont les traductions de ces documents. Ne les
modifiez pas, les traductions sont gérées par
@uref{https://translate.fedoraproject.org/projects/guix,
Weblate}. @xref{Traduire Guix} pour plus de détails.

Pour générer la documentation, vous devez d'abord vous assurer d'avoir lancé
@command{./configure} dans votre arborescence des sources (@pxref{Lancer Guix avant qu'il ne soit installé}). Ensuite, vous pourrez lancer l'une des
commandes suivantes :

@itemize
@item @samp{make doc/guix.info} pour compiler le manuel Info.
      Vous pouvez le consulter avec @command{info doc/guix.info}.
@item @samp{make doc/guix.html} pour compiler la version HTML.
      Vous pouvez pointer votre navigateur vers le fichier qui vous intéresse dans
le répertoire @file{doc/guix.html}.
@item @samp{make doc/guix-cookbook.info} pour le manuel Info du livre de recettes.
@item @samp{make doc/guix-cookbook.html} pour la version HTML du livre de recettes.
@end itemize

@cindex traduction
@cindex l10n
@cindex i18n
@cindex prise en charge des langues
@node Traduire Guix
@section Traduire Guix

Écrire du code et des paquets n'est pas la seule manière possible de
proposer une contribution intéressante à Guix. Traduire vers une langue que
vous parlez est un autre exemple de contribution importante que vous pouvez
faire. Cette section décrit le processus de traduction. Elle vous donner des
conseils sur comment vous impliquer, ce qui peut être traduit, les erreurs à
éviter et ce que vous pouvez faire pour nous aider !

Guix est un gros projet qui a plusieurs composants traduisibles. Nous
coordonnons l'effort de traduction sur une
@uref{https://translate.fedoraproject.org/projects/guix/,instance Weblate}
hébergée par nos amis de Fedora. Vous aurez besoin d'un compte pour
soumettre vos traductions.

Certains logiciels empaquetés par Guix contiennent aussi des
traductions. Nous n'hébergeons pas de plateforme de traduction pour eux. Si
vous voulez traduire un paquet fournit par Guix, vous devrez contacter ses
développeurs ou trouver plus d'information sur son site web. Par exemple,
vous pouvez trouver la page d'accueil du paquet @code{hello} en lançant
@code{guix show hello}. Sur la ligne indiquant « homepage », vous verrez que
la page d'accueil est @url{https://www.gnu.org/software/hello/}.

De nombreux paquets GNU et non-GNU peuvent être traduits sur le
@uref{https://translationproject.org,Projet de traduction}. Certains projets
avec de multiples composants ont leur propre plateforme. Par exemple, GNOME
a sa propre plateforme, @uref{https://l10n.gnome.org/,Damned Lies}.

Guix a cinq composants hébergés sur Weblate.

@itemize
@item @code{guix} contient toutes les chaînes du logiciel Guix (le guide
      d'installation du système, le gestionnaire de paquets, etc), en dehors des
paquets.
@item @code{packages} contient le synopsis (une description courte en
      une ligne) et la description (longue) des paquets de Guix.
@item @code{website} contient le site web officiel de Guix, en dehors
      des billets de blog et du contenu multimédia.
@item @code{documentation-manual} correspond à ce manuel.
@item @code{documentation-cookbook} est le composant du livre de recettes.
@end itemize

@subsubheading Instructions générales

Une fois que vous aurez un compte, vous pourrez choisir un composant dans
@uref{https://translate.fedoraproject.org/projects/guix/,projet guix}, et
choisir une langue. Si votre langue n'apparaît pas dans la liste, allez en
bas et cliquez sur le bouton « commencer une nouvelle traduction
». Choisissez la langue en laquelle vous voulez traduire dans la liste pour
commencer votre nouvelle traduction.

Comme de nombreux autres logiciels libres, Guix utilise
@uref{https://www.gnu.org/software/gettext,GNU Gettext} pour ses
traductions. Grâce à lui, les chaînes traduisibles sont extraites du code
source en des fichier dits PO.

Même si les fichiers PO sont des fichiers textes, vous devriez les modifier
non pas avec un éditeur de texte mais avec un logiciel d'édition de
PO. Weblate intègre une fonctionnalité d'édition de PO. Autrement, vous
pouvez utiliser n'importe lequel des divers outils libres pour remplir les
traductions, dont @uref{https://poedit.net/,Poedit} est un exemple, et
(après vous être connecté)
@uref{https://docs.weblate.org/en/latest/user/files.html,téléverser} le
fichier modifié. Il y a aussi un
@uref{https://www.emacswiki.org/emacs/PoMode,mode d'édition de PO} spécial
pour GNU Emacs. Avec le temps vous trouverez les logiciels qui vous
satisfont et les fonctionnalités dont vous avez besoin.

Sur Weblate, vous trouverez plusieurs liens vers l'éditeur, qui vous
montreront divers sous-ensemble (ou la totalité) des chaînes. Explorez
Weblate et consultez la
@uref{https://docs.weblate.org/fr/latest/,documentation} pour vous
familiariser avec la plateforme.

@subsubheading Composants des traductions

Dans cette section, nous proposons un guide plus détaillé du processus de
traduction, ainsi que des détails sur ce que vous devriez ou ne devriez pas
faire. Si vous avez un doute, contactez-nous, nous serons ravis de vous
aider !

@table @asis
@item guix
Guix est écrit dans le langage de programmation Guile, et certaines chaînes
contiennent du formatage spécial interprété par Guile. Ce formatage spécial
devrait être mis en évidence par Weblate. Il commence par @code{~} suivi
d'un ou plusieurs caractères.

Lors de l'affichage des chaînes, Guile remplace les symboles de formatage
spéciaux avec les vrais valeurs. Par exemple, la chaîne @samp{ambiguous
package specification `~a'} serait modifiée pour contenir la spécification
du paquet en question au lieu de @code{~a}. Pour traduire cette chaîne
correctement, vous devez garder le formatage dans vos traduction, même si
vous pouvez le placer là où cela a le plus de sens dans votre langue. Par
exemple, la traduction française dit @samp{spécification du paquet « ~a »
ambiguë} parce que l'adjectif doit être placé à la fin de la phrase.

S'il y a plusieurs symboles de formatage, assurez-vous de respecter
l'ordre. Guile ne sait pas dans quel ordre vous voulez qu'il lise la chaîne,
donc il remplacera les symboles dans le même ordre que la phrase anglaise.

Par exemple, vous ne pouvez pas traduire @samp{package '~a' has been
superseded by '~a'} par @samp{« ~a » remplace le paquet « ~a »}, parce que
le sens serait renversé. Si @var{toto} est remplacé par @var{titi}, la
traduction dirait @samp{« toto » remplace le paquet « titi »}. Pour éviter
ce problème, il est possible d'utiliser un formatage plus avancé pour
désigner une donnée particulière, au lieu de suivre l'ordre anglais par
défaut. @xref{Formatted Output,,, guile, GNU Guile Reference Manual}, pour
plus d'information sur le formatage en Guile.

@item paquets

Les descriptions de paquets contiennent parfois du balisage Texinfo
(@pxref{Synopsis et descriptions}). Le balisage Texinfo ressemble à
@samp{@@code@{rm -rf@}}, @samp{@@emph@{important@}}, etc. Lors de la
traduction, laissez le balisage tel quel.

Les caractères après « @@ » forment le nom de la balise, et le texte entre «
@{ » et « @} » est son contenu. En général, vous ne devriez pas traduire le
contenu des balises comme @code{@@code}, car elles contiennent littéralement
du code qui ne change pas avec la langue. Vous pouvez traduire le contenu
des balises de formatage comme @code{@@emph}, @code{@@i}, @code{@@itemize},
@code{@@item}. Cependant, ne traduisez pas le nom de la balise, ou elle ne
sera plus reconnue. Ne traduisez pas le mot après @code{@@end}, c'est le nom
de la balise fermée à cet endroit (p. ex.  @code{@@itemize ... @@end
itemize}).

@item documentation-manual et documentation-cookbook

La première étape pour assurer la traduction du manuel est de trouver et
traduire les chaîne suivantes @emph{en premier} :

@itemize
@item @code{version.texi} : Traduisez cette chaîne en @code{version-xx.texi},
      où @code{xx} est le code de votre langue (celui affiché dans l'URL sur
weblate).
@item @code{contributing.texi} : Traduisez cette chaîne en
      @code{contributing.xx.texi}, où @code{xx} est le même code de langue.
@item @code{Top} : Ne traduisez pas cette chaîne, c'est important pour Texinfo.
      Si vous la traduisez, le document sera vide (il manquera le nœud
Top). Cherchez-là et utilisez @code{Top} comme traduction.
@end itemize

Traduire ces chaînes en premier s'assure que nous pouvez inclure vos
traduction dans le dépôt guix sans casser le processus make ni la machinerie
derrière @command{guix pull}.

Le manuel et le livre de recettes utilisent tous les deux Texinfo. Comme
pour @code{packages}, gardez le balisage Texinfo intact. Il y a plus de
types de balises possibles dans le manuel que dans les descriptions de
paquets. En général, ne traduisez pas le contenu de @code{@@code},
@code{@@file}, @code{@@var}, @code{@@value}, etc. Vous devriez traduire le
contenu des balises de formatage comme @code{@@emph}, @code{@@i}, etc.

Le manuel contient des sections auxquelles on peut se référer par leur nom
avec @code{@@ref}, @code{@@xref} et @code{@@pxref}. Nous avons mis en place
un mécanisme pour que vous n'ayez pas besoin de traduire leur contenu. Si
vous gardez le titre anglais, nous le remplacerons automatiquement par votre
traduction de ce titre. Cela s'assure que Texinfo sera toujours capable de
trouver le nœud. Si vous décidez de changer la traduction du titre, les
références seront automatiquement mises à jour et vous n'aurez pas à les
mettre à jour vous-même.

Lorsque vous traduirez des références de livre de recettes vers le manuel,
vous devrez remplacer le nom du manuel et le nom de la section. Par exemple,
pour traduire @code{@@pxref@{Defining Packages,,, guix, GNU Guix Reference
Manual@}}, vous devrez remplacer @code{Defining Packages} par le titre de
cette section dans le manuel traduit @emph{seulement} si ce titre est
traduit. Si le titre n'est pas encore traduit dans votre langue, ne le
traduisez pas ici, ou le lien sera cassé. Remplacez @code{guix} par
@code{guix.xx} où @code{xx} est le code de votre langue. @code{GNU Guix
Reference Manual} est le texte du lien. Vous pouvez le traduire comme bon
vous semble.

@item website

Les pages du site web sont écrite en SXML, une manière d'écrire du HTML, le
langage de base du web, avec des s-expressions. Nous avons un processus pour
extraire les chaînes traduisibles dans les sources, et pour remplacer les
s-expressions complexes avec du balisage XML plus familier, où chaque balise
est numérotée. Vous pouvez changer l'ordre comme bon vous semble, comme dans
l'exemple suivant.

@example
#. TRANSLATORS: Defining Packages is a section name
#. in the English (en) manual.
#: apps/base/templates/about.scm:64
msgid "Packages are <1>defined<1.1>en</1.1><1.2>Defining-Packages.html</1.2></1> as native <2>Guile</2> modules."
msgstr "Pakete werden als reine <2>Guile</2>-Module <1>definiert<1.1>de</1.1><1.2>Pakete-definieren.html</1.2></1>."
@end example

Remarquez que vous devez inclure les même balises. Vous ne devez pas en
oublier.
@end table

Si vous faites une erreur, le composant peut échouer à construire
correctement dans votre langue, voir casser guix pull. Pour éviter cela,
nous avons mis en place un processus pour vérifier le contenu des fichiers
avant de les pousser dans notre dépôt. Nous ne pourrons alors pas mettre à
jour la traduction en votre langue dans Guix, donc nous vous notifierons (à
travers weblate ou par courriel) pour que vous puissez corriger le problème.

@subsubheading En dehors de Weblate

Actuellement, certaines parties de Guix ne peuvent pas être traduites sur
Weblate, nous avons besoin d'aide !

@itemize
@item Les nouvelles de @command{guix pull} peuvent être traduites dans @file{news.scm}, mais ne sont
      pas disponibles sur Weblate. Si vous voulez fournir une traduction, vous
pouvez préparer un correctif comme décrit plus haut, ou simplement nous
envoyer votre traduction avec le nom de l'entrée que vous avez traduite et
votre langue. @xref{Écrire des nouveautés de canaux}, pour plus d'information sur les
nouvelles de canaux.
@item Les billets de blog de Guix ne peuvent pas encore être traduits.
@item Le script d'installation (pour les distributions externes) est entièrement en anglais.
@item Certaines bibliothèques que Guix utilise ne peuvent pas être traduites ou leurs traductions
      sont en dehors du projet Guix. Guile lui-même n'est pas internationalisé.
@item Les liens vers les autres manuels ici ou dans le livre de recettes ne sont pas
      forcément traduits.
@end itemize

@subsubheading Conditions d'inclusion

Il n'y a pas de condition particulière pour ajouter de nouvelles traductions
aux composants @code{guix} et @code{guix-packages}, en dehors du fait
qu'elles doivent avoir au moins une chaîne traduite. Les nouvelles langues
seront ajoutées à Guix le plus tôt possible. Les fichiers peuvent être
supprimés s'ils ne sont plus synchronisés et qu'ils n'ont plus aucune chaîne
traduite.

Étant donné que le site web est prévu pour les nouveaux utilisateurs, nous
souhaitons que ses traductions soient les plus complètes possible avant de
les inclure dans le menu des langues. Pour qu'une nouvelle langue soit
ajoutée, elle doit atteindre au moins les 80% de complétion. Lorsqu'une
langue est incluse, elle peut être supprimée dans le futur si elle reste
désynchronisée et que sa complétion descend en dessous des 60%.

Le manuel et le livre de recettes sont automatiquement ajoutés à la cible de
compilation par défaut. Chaque fois que nous synchronisons les traductions,
les développeurs et développeuses doivent recompiler tous les manuels et les
livres de recettes traduits. C'est inutile s'il s'agit en grande partie du
manuel ou du livre de recettes en anglais. De ce fait, nous n’inclurons les
nouvelles langues que si elles atteignent 10% de complétion dans le
composant en question. Lorsqu'une langue est ajoutée, elle pourra être
supprimée dans le futur si elle reste désynchronisée et que son taux de
complétion descend en dessous des 5%.

@subsubheading Infrastructure de traduction

Weblate s'appuie sur un dépôt git à partir duquel il découvre les nouvelles
chaînes à traduire et vers lequel il pousse les nouvelles
traductions. Normalement, il suffirait de lui donner accès en commit à nos
dépôts. Cependant, nous avons préféré utiliser un dépôt séparé pour deux
raisons. Tout d'abord, nous aurions du donner à Weblate l'accès en commit et
autoriser sa clé de signature, mais nous ne lui faisons pas autant confiance
qu'aux développeurs de guix, d'autant plus que nous ne gérons pas l'instance
nous-même. Ensuite, si les traducteurs et les traductrices font une erreur,
cela peut casser la génération du site web ou guix pull pour tout le monde,
quelle que soit la langue.

Pour ces raisons, nous utilisons un dépôt dédié pour héberger les
traductions, et nous le synchronisons avec nos dépôts guix et artwork après
avoir vérifié qu'aucun problème n'est introduit par les traductions.

vous pouvez télécharger les derniers fichiers PO de weblate dans le dépôt
Guix en lançant la commande @command{make download-po}. Cela télécharge
automatiquement les derniers fichiers de weblate, les reformate vers une
forme canonique, et vérifie qu'ils ne contiennent pas de problème. Le manuel
doit être reconstruit pour vérifier qu'il n'y a pas de problème
supplémentaire qui ferait planter Texinfo.

Avant de pousser de nouveaux fichiers de traduction, qui n'existaient pas
avant, vous devez les ajouter à la machinerie make pour que les traductions
soit effectivement disponibles. Le processus diffère en fonction des
composants.

@itemize
@item Les nouveau fichiers po pour les composants @code{guix} et @code{packages} doivent
      être enregistrés en ajoutant la nouvelle langue dans @file{po/guix/LINGUAS}
ou @file{po/packages/LINGUAS}.
@item Le nouveaux fichiers pour le composant @code{documentation-manuel} doivent
      être enregistrés en ajoutant le nom de fichier à @code{DOC_PO_FILES} dans
@file{po/doc/local.mk}, le manuel généré @file{%D%/guix.xx.texi} à
@code{info_TEXINFOS} dans @file{doc/local.mk} et les fichiers
@file{%D%/guix.xx.texi} et @file{%D%/contributing.xx.texi} à
@code{TRANSLATED_INFO} aussi dans @file{doc/local.mk}.
@item Les nouveaux fichiers po pour le composant @code{documentation-cookbook} doivent
      être enregistrés en ajoutant le nom de fichier à
@code{DOC_COOKBOOK_PO_FILES} dans @file{po/doc/local.mk}, le manuel généré
@file{%D%/guix-cookbook.xx.texi} à @code{info_TEXINFOS} dans
@file{doc/local.mk} et le fichier généré @file{%D%/guix-cookbook.xx.texi} à
@code{TRANSLATED_INFO} aussi dans @file{doc/local.mk}.
@item Les nouveau fichiers po pour le composant @code{website} doivent être ajoutés dans
      le dépôt @code{guix-artwork}, dans @file{website/po/}. Vous devez mettre à
jour @file{website/po/LINGUAS} et @file{website/po/ietf-tags.scm} en
fonction (voir @file{website/i18n-howto.txt} pour plus d'information sur le
processus).
@end itemize
