Contribuer
**********

Ce projet est un effort coopératif et nous avons besoin de votre aide pour le faire grandir ! Contactez-nous sur guix-devel@gnu.org et #guix sur le réseau IRC Freenode.  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 (see Consignes d'empaquetage).

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 http://contributor-covenant.org/.  Vous pouvez trouver une version locale dans le fichier CODE-OF-CONDUCT dans l'arborescence des sources.

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

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 :

     git clone https://git.savannah.gnu.org/git/guix.git

Lors de la construction de Guix depuis un extrait, les paquets suivants sont requis en plus de ceux mentionnés dans les instructions d'installation (see Prérequis).

  * GNU Autoconf (http://gnu.org/software/autoconf/);

  * GNU Automake (http://gnu.org/software/automake/);

  * GNU Gettext (http://gnu.org/software/gettext/);

  * GNU Texinfo (http://gnu.org/software/texinfo/);

  * Graphviz (http://www.graphviz.org/);

  * GNU Help2man (facultatif) (http://www.gnu.org/software/help2man/).

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 :

     guix environment guix

See Invoquer guix environment, pour plus d'information sur cette commande.  On peut ajouter des dépendances supplémentaires avec --ad-hoc :

     guix environment guix --ad-hoc help2man git strace

Lancez ./bootstrap pour générer l'infrastructure du système de construction avec Autoconf et Automake.  Si vous avez une erreur comme :

     configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES

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

     export ACLOCAL_PATH=/usr/share/aclocal

See Macro Search Path (The GNU Automake Manual), pour plus d'information.

Ensuite, lancez ./configure comme d'habitude.  Assurez-vous de passer --localstatedir=DIRECTORY où DIRECTORY est la valeur localstatedir utilisée par votre installation actuelle (see Le dépôt pour plus d'informations à ce propos).

Finalement, vous devez invoquer make check pour lancer les tests (see Lancer la suite de tests).  Si quelque chose échoue, jetez un œil aux instructions d'installation (see Installation) ou envoyez un message à la list guix-devel@gnu.org.

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 final » de celui parfois haut en couleur de « développeur ».

Pour cela, tous les outils en ligne de commande sont utilisables même sans avoir lancé make install.  Pour cela, vous devez d'abord avoir un environnement avec toutes les dépendances disponibles (see Construire depuis Git), puis préfixer chaque commande par ./pre-inst-env (le script 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é par ./configure) comme cela (L'option -E de sudo garantie que GUILE_LOAD_PATH est bien paramétré pour guix-daemon et pour que les outils qu'il utilise puissent trouver les modules Guile dont ils ont besoin.) :

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

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

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

     ;;; ("x86_64-linux")

... et pour un REPL (see Using Guile Interactively (Guile Reference Manual))

     $ ./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

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

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

La configuration parfaite
=========================

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

Geiser permet le développement interactif et incrémental depuis Emacs : la compilation du code et son évaluation depuis les buffers, l'accès à la documentation en ligne (docstrings), la complétion sensible au contexte, M-. pour sauter à la définition d'un objet, un REPL pour tester votre code, et bien plus (see Introduction (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 :

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

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 Paredit (http://www.emacswiki.org/emacs/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.

Nous fournissons aussi des modèles pour les messages de commit git communs et les définitions de paquets dans le répertoire etc/snippets.  Ces modèles s'utilisent avec YASnippet (http://joaotavora.github.io/yasnippet/) pour développer des chaînes courtes de déclenchement en extraits de texte interactifs.  Vous pouvez ajouter le répertoire des modèles dans la variables YAS-SNIPPET-DIRS d'Emacs.

     ;; Si l'extrait est dans ~/src/guix.
     (with-eval-after-load 'yasnippet
       (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))

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

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

Style de code
=============

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

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 memoize.

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 (guix build ...).  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 (gnu ...) plutôt que (guix ...).

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 car, cdr, 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.

Le code de Guix devrait définir des types de données appropriées (par exemple, avec define-record-type*) plutôt que d'abuser des listes. En plus, il devrait utiliser la recherche de motifs, via le module Guile (ice-9 match), surtout pour rechercher dans des listes.

Formatage du code
-----------------

Lorsque nous écrivons du code Scheme, nous suivons la sagesse commune aux programmeurs Scheme.  En général, nous suivons les règles de style de Riastradh (http://mumble.net/~campbell/scheme/style.txt).  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 substitute* ont des règles d'indentation spécifiques.  Elles sont définies dans le fichier .dir-locals.el qu'Emacs utilise automatiquement.  Remarquez aussi qu'Emacs-Guix fournit le mode guix-devel-mode qui indente et colore le code Guix correctement (see Development (The Emacs-Guix Reference Manual)).

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 :

     ./etc/indent-code.el gnu/packages/FILE.scm PACKAGE

Cela indente automatiquement la définition de PACKAGE dans gnu/packages/FILE.scm en lançant Emacs en mode commande.  Pour indenter un fichier complet, n'indiquez pas de second argument :

     ./etc/indent-code.el gnu/services/FILE.scm

Si vous éditez du code avec Vim, nous recommandons de lancer :set autoindent pour que votre code soit automatiquement indenté au moment où vous l'entrez.  En plus, paredit.vim (https://www.vim.org/scripts/script.php?script_id=3998) 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 (guix build ...) cependant.

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

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 git format-patch envoyés sur la liste de diffusion guix-patches@gnu.org.

Cette liste de diffusion est gérée par une instance Debbugs accessible à l'adresse https://bugs.gnu.org/guix-patches, qui nous permet de suivre les soumissions.  Chaque message envoyé à cette liste se voit attribuer un numéro de suivi ; les gens peuvent ensuite répondre à cette soumission en envoyant un courriel à NNN@debbugs.gnu.org, où NNN est le numéro de suivi (see Envoyer une série de correctifs).

Veuillez écrire les messages de commit dans le format ChangeLog (see Change Logs (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 :

 1. Si les auteurs du paquet logiciel fournissent une signature cryptographique pour l'archive, faîtes un effort pour vérifier l'authenticité de l'archive. Pour un fichier de signature GPG détaché, cela se fait avec la commande gpg --verify.

 2. Prenez un peu de temps pour fournir un synopsis et une description adéquats pour le paquet.  Voir Synopsis et descriptions pour quelques lignes directrices.

 3. Lancez guix lint PAQUET, où PAQUET est le nom du nouveau paquet ou du paquet modifié, et corrigez les erreurs qu'il rapporte (see Invoquer guix lint).

 4. Assurez-vous que le paquet se construise sur votre plate-forme avec guix build PAQUET.

 5. 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 de leurs utilisateurs.  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.

 6. Regardez le profile rapporté par guix size (see Invoquer guix size).  Cela vous permettra de remarquer des références à d'autres paquets qui ont été retenus.  Il peut aussi aider à déterminer s'il faut découper le paquet (see Des paquets avec plusieurs résultats) et quelle dépendance facultative utiliser.

 7. Pour les changements important, vérifiez que les paquets qui en dépendent (s'ils existent) ne sont pas affectés par le changement ; guix refresh --list-dependant PAQUET vous aidera (see Invoquer guix refresh).

     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 :

     300 paquets dépendants ou moins
          branche master (changements non-disruptifs).

     entre 300 et 1 200 paquets dépendants
          branche staging (changemets non-disruptifs).  Cette branche devrait être fusionnées dans master tous les 3 semaines.  Les changements par thèmes (par exemple une mise à jour de la pile GNOME) peuvent aller dans une branche spécifique (disons, gnome-updates).

     plus de 1 200 paquets dépendants
          branche core-updates (peut inclure des changements majeurs et potentiellement disruptifs).  Cette branche devrait être fusionnée dans master tous les 2,5 mois environ.

     Toutes ces branches sont gérées par notre ferme de construction (https://hydra.gnu.org/project/gnu) et fusionnées dans master une fois que tout a été construit correctement.  Cela nous permet de corriger des problèmes avant qu'ils n'atteignent les utilisateurs et réduit la fenêtre pendant laquelle les binaires pré-construits ne sont pas disponibles.

     Généralement les autres branches que master sont considérées comme gelées s'il y a eu une évaluation récente ou qu'il y a une branche -next correspondante.  Demandez sur la liste de diffusion ou sur IRC si vous n'êtes pas sûr de savoir où pousser votre correctif.

 8. 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 (see Invoquer guix build) :

          guix build --rounds=2 mon-paquet

     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 guix challenge (see Invoquer guix challenge).  Vous pouvez lancer la commande une fois que les paquets ont été commités et construits par hydra.gnu.org 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 guix publish.  Puis 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 uname ou les fichiers de /proc.

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

 10. 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.

 11. Suivez nos règles de formatage de code, éventuellement en lançant le script et/indent-code.el pour le faire automatiquement (see Formatage du code).

 12. Si possible, utilisez des miroirs dans l'URL des sources (see 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 name dans l'URL : ce n'est pas très utile et si le nom change, l'URL sera probablement erronée.

Lorsque vous envoyez un correctif à la liste de diffusion, utilisez [PATCH] ... comme sujet.  Vous pouvez utiliser votre client de courriel ou la commande git send-email (see Envoyer une série de correctifs).  Nous préférons recevoir des correctifs en texte brut, soit en ligne, soit en pièce-jointe MIME.   Nous vous conseillons de faire attention si votre client de courriel change par exemple les retours à la ligne ou l'indentation, ce qui peut casser les correctifs.

Lorsqu'un bogue est résolu, veuillez fermer le fil en envoyant un courriel à NNN-done@debbugs.gnu.org.

Envoyer une série de correctifs
-------------------------------

Lorsque vous envoyez une série de correctifs (p.@:: ex. avec git send-email), envoyez d'abord une premier message à guix-patches@gnu.org puis envoyez le reste des correctifs à NNN@debbugs.gnu.org pour vous assurer qu'ils seront groupés ensemble.  Voyez la documentation de Debbugs (https://debbugs.gnu.org/Advanced.html) pour plus d'informations.