You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

1008 lines
45 KiB

  1. @node Contribuer
  2. @chapter Contribuer
  3. Ce projet est un effort coopératif et nous avons besoin de votre aide pour
  4. le faire grandir ! Contactez-nous sur @email{guix-devel@@gnu.org} et
  5. @code{#guix} sur le réseau IRC Freenode. Nous accueillons les idées, les
  6. rapports de bogues, les correctifs et tout ce qui pourrait aider le projet.
  7. Nous apprécions particulièrement toute aide sur la création de paquets
  8. (@pxref{Consignes d'empaquetage}).
  9. @cindex code de conduite, des contributeurs
  10. @cindex convention de contribution
  11. Nous souhaitons fournir un environnement chaleureux, amical et sans
  12. harcèlement pour que tout le monde puisse contribuer au mieux de ses
  13. capacités. Pour cela notre projet a une « Convention de contribution »
  14. adaptée de @url{http://contributor-covenant.org/}. Vous pouvez trouver une
  15. version locale dans le fichier @file{CODE-OF-CONDUCT} dans l'arborescence
  16. des sources.
  17. Les contributeurs n'ont pas besoin d'utiliser leur nom légal dans leurs
  18. correctifs et leurs communications en ligne ; ils peuvent utiliser n'importe
  19. quel nom ou pseudonyme de leur choix.
  20. @menu
  21. * Construire depuis Git:: Toujours le plus récent.
  22. * Lancer Guix avant qu'il ne soit installé:: Astuces pour les hackers.
  23. * La configuration parfaite:: Les bons outils.
  24. * Consignes d'empaquetage:: Faire grandir la distribution.
  25. * Style de code:: Hygiène du contributeur.
  26. * Envoyer des correctifs:: Partager votre travail.
  27. @end menu
  28. @node Construire depuis Git
  29. @section Construire depuis Git
  30. Si vous souhaitez travailler sur Guix lui-même, il est recommandé d'utiliser
  31. la dernière version du dépôt Git :
  32. @example
  33. git clone https://git.savannah.gnu.org/git/guix.git
  34. @end example
  35. Lors de la construction de Guix depuis un extrait, les paquets suivants sont
  36. requis en plus de ceux mentionnés dans les instructions d'installation
  37. (@pxref{Prérequis}).
  38. @itemize
  39. @item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
  40. @item @url{http://gnu.org/software/automake/, GNU Automake};
  41. @item @url{http://gnu.org/software/gettext/, GNU Gettext};
  42. @item @url{http://gnu.org/software/texinfo/, GNU Texinfo};
  43. @item @url{http://www.graphviz.org/, Graphviz};
  44. @item @url{http://www.gnu.org/software/help2man/, GNU Help2man (facultatif)}.
  45. @end itemize
  46. La manière la plus simple de configurer un environnement de développement
  47. pour Guix est, bien sûr, d'utiliser Guix ! La commande suivante démarre un
  48. nouveau shell où toutes les dépendances et les variables d'environnements
  49. appropriées sont configurés pour travailler sur Guix :
  50. @example
  51. guix environment guix
  52. @end example
  53. @xref{Invoquer guix environment}, pour plus d'information sur cette
  54. commande. On peut ajouter des dépendances supplémentaires avec
  55. @option{--ad-hoc} :
  56. @example
  57. guix environment guix --ad-hoc help2man git strace
  58. @end example
  59. Lancez @command{./bootstrap} pour générer l'infrastructure du système de
  60. construction avec Autoconf et Automake. Si vous avez une erreur comme :
  61. @example
  62. configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
  63. @end example
  64. @noindent
  65. cela signifie probablement qu'Autoconf n'a pas pu trouver @file{pkg.m4} qui
  66. est fournit par pkg-config. Assurez-vous que @file{pkg.m4} est disponible.
  67. C'est aussi vrai pour l'ensemble de macros de @file{guile.m4} fournies par
  68. Guile. Par exemple, si vous avez installé Automake dans @file{/usr/local},
  69. il ne cherchera pas les fichiers @file{.m4} dans @file{/usr/share}. Dans ce
  70. case vous devez invoquer la commande suivante :
  71. @example
  72. export ACLOCAL_PATH=/usr/share/aclocal
  73. @end example
  74. @xref{Macro Search Path,,, automake, The GNU Automake Manual}, pour plus
  75. d'information.
  76. Ensuite, lancez @command{./configure} comme d'habitude. Assurez-vous de
  77. passer @code{--localstatedir=@var{directory}} où @var{directory} est la
  78. valeur @code{localstatedir} utilisée par votre installation actuelle
  79. (@pxref{Le dépôt} pour plus d'informations à ce propos).
  80. Finalement, vous devez invoquer @code{make check} pour lancer les tests
  81. (@pxref{Lancer la suite de tests}). Si quelque chose échoue, jetez un œil
  82. aux instructions d'installation (@pxref{Installation}) ou envoyez un message
  83. à la liste @email{guix-devel@@gnu.org}.
  84. @node Lancer Guix avant qu'il ne soit installé
  85. @section Lancer Guix avant qu'il ne soit installé
  86. Pour garder un environnement de travail sain, il est utile de tester les
  87. changement localement sans les installer pour de vrai. Pour pouvoir
  88. distinguer votre rôle « d'utilisateur final » de celui parfois haut en
  89. couleur de « développeur ».
  90. Pour cela, tous les outils en ligne de commande sont utilisables même sans
  91. avoir lancé @code{make install}. Pour cela, vous devez d'abord avoir un
  92. environnement avec toutes les dépendances disponibles (@pxref{Construire depuis Git}), puis préfixer chaque commande par @command{./pre-inst-env} (le script
  93. @file{pre-inst-env} se trouve dans le répertoire de plus haut niveau de
  94. l'arborescence des sources de Guix ; il est généré par
  95. @command{./configure}) comme cela@footnote{L'option @option{-E} de
  96. @command{sudo} garantie que @code{GUILE_LOAD_PATH} est bien paramétré pour
  97. @command{guix-daemon} et pour que les outils qu'il utilise puissent trouver
  98. les modules Guile dont ils ont besoin.} :
  99. @example
  100. $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
  101. $ ./pre-inst-env guix build hello
  102. @end example
  103. @noindent
  104. De même, pour une session Guile qui utilise les modules Guix :
  105. @example
  106. $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
  107. ;;; ("x86_64-linux")
  108. @end example
  109. @noindent
  110. @cindex REPL
  111. @cindex read-eval-print loop
  112. @dots{} et pour un REPL (@pxref{Using Guile Interactively,,, guile, Guile
  113. Reference Manual})
  114. @example
  115. $ ./pre-inst-env guile
  116. scheme@@(guile-user)> ,use(guix)
  117. scheme@@(guile-user)> ,use(gnu)
  118. scheme@@(guile-user)> (define snakes
  119. (fold-packages
  120. (lambda (package lst)
  121. (if (string-prefix? "python"
  122. (package-name package))
  123. (cons package lst)
  124. lst))
  125. '()))
  126. scheme@@(guile-user)> (length snakes)
  127. $1 = 361
  128. @end example
  129. Le script @command{pre-inst-env} paramètre toutes les variables
  130. d'environnement nécessaires, dont @env{PATH} et @env{GUILE_LOAD_PATH}.
  131. Remarquez que @command{./pre-inst-env guix pull} ne met @emph{pas} à jour
  132. l'arborescence des sources locale ; cela met seulement à jour le lien
  133. symbolique de @file{~/.config/guix/current} (@pxref{Invoquer guix pull}).
  134. Lancez @command{git pull} à la place si vous voulez mettre à jour votre
  135. arborescence des source locale.
  136. @node La configuration parfaite
  137. @section La configuration parfaite
  138. La configuration parfaite pour travailler sur Guix est simplement la
  139. configuration parfaite pour travailler en Guile (@pxref{Using Guile in
  140. Emacs,,, guile, Guile Reference Manual}). Tout d'abord, vous avez besoin de
  141. mieux qu'un éditeur de texte, vous avez besoin de
  142. @url{http://www.gnu.org/software/emacs, Emacs}, amélioré par le superbe
  143. @url{http://nongnu.org/geiser/, Geiser}. Pour paramétrer cela, lancez :
  144. @example
  145. guix package -i emacs guile emacs-geiser
  146. @end example
  147. Geiser permet le développement interactif et incrémental depuis Emacs : la
  148. compilation du code et son évaluation depuis les buffers, l'accès à la
  149. documentation en ligne (docstrings), la complétion sensible au contexte,
  150. @kbd{M-.} pour sauter à la définition d'un objet, un REPL pour tester votre
  151. code, et bien plus (@pxref{Introduction,,, geiser, Geiser User Manual}).
  152. Pour travailler confortablement sur Guix, assurez-vous de modifier le chemin
  153. de chargement de Guile pour qu'il trouve les fichiers source de votre dépôt
  154. :
  155. @lisp
  156. ;; @r{Si l'extrait est dans ~/src/guix.}
  157. (with-eval-after-load 'geiser-guile
  158. (add-to-list 'geiser-guile-load-path "~/src/guix"))
  159. @end lisp
  160. Pour effectivement éditer le code, Emacs a déjà un très bon mode Scheme.
  161. Mais en plus de ça, vous ne devez pas rater
  162. @url{http://www.emacswiki.org/emacs/ParEdit, Paredit}. Il fournit des
  163. fonctionnalités pour opérer directement sur l'arbre de syntaxe, comme
  164. relever une s-expression ou l'envelopper, absorber ou rejeter la
  165. s-expression suivante, etc.
  166. @cindex extraits de code
  167. @cindex modèles
  168. @cindex réduire la quantité de code commun
  169. Nous fournissons aussi des modèles pour les messages de commit git communs
  170. et les définitions de paquets dans le répertoire @file{etc/snippets}. Ces
  171. modèles s'utilisent avec @url{http://joaotavora.github.io/yasnippet/,
  172. YASnippet} pour développer des chaînes courtes de déclenchement en extraits
  173. de texte interactifs. Vous pouvez ajouter le répertoire des modèles dans la
  174. variables @var{yas-snippet-dirs} d'Emacs.
  175. @lisp
  176. ;; @r{Si l'extrait est dans ~/src/guix.}
  177. (with-eval-after-load 'yasnippet
  178. (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))
  179. @end lisp
  180. Les extraits de messages de commit dépendent de @url{https://magit.vc/,
  181. Magit} pour afficher les fichiers sélectionnés. Lors de la modification
  182. d'un message de commit, tapez @code{add} suivi de @kbd{TAB} pour insérer un
  183. modèle de message de commit pour ajouter un paquet ; tapez @code{update}
  184. suivi de @kbd{TAB} pour insérer un modèle pour la mise à jour d'un paquet ;
  185. tapez @code{https} suivi de @kbd{TAB} pour insérer un modèle pour le
  186. changement à HTTPS de l'URI de la page d'accueil.
  187. L'extrait principal pour @code{scheme-mode} est lancé en tapant
  188. @code{package…} suivi par @kbd{TAB}. Cet extrait insère aussi la chaîne de
  189. déclenchement @code{origin…}, qui peut aussi être étendue. L'extrait
  190. @code{origin} lui-même peut aussi insérer des chaînes de déclenchement qui
  191. finissent sur @code{…}, qui peuvent aussi être étendues.
  192. @node Consignes d'empaquetage
  193. @section Consignes d'empaquetage
  194. @cindex paquets, création
  195. La distribution GNU est jeune et vos paquets préférés peuvent manquer.
  196. Cette section décrit comment vous pouvez aider à agrandir la distribution.
  197. Les paquets de logiciels libres sont habituellement distribués sous forme
  198. @dfn{d'archives de sources} — typiquement des fichiers @file{.tar.gz}
  199. contenant tous les fichiers sources. Ajouter un paquet à la distribution
  200. signifie essentiellement deux choses : ajouter une @dfn{recette} qui décrit
  201. comment construire le paquet, avec une liste d'autres paquets requis pour le
  202. construire, et ajouter des @dfn{métadonnées de paquet} avec la recette,
  203. comme une description et une licence.
  204. Dans Guix, toutes ces informations sont incorporées dans les
  205. @dfn{définitions de paquets}. Les définitions de paquets fournissent une
  206. vue de haut-niveau du paquet. Elles sont écrites avec la syntaxe du langage
  207. de programmation Scheme ; en fait, pour chaque paquet nous définissons une
  208. variable liée à la définition et exportons cette variable à partir d'un
  209. module (@pxref{Modules de paquets}). Cependant, il n'est @emph{pas} nécessaire
  210. d'avoir une connaissance approfondie du Scheme pour créer des paquets. Pour
  211. plus d'informations sur les définitions des paquets, @pxref{Définition des paquets}.
  212. Une fois une définition de paquet en place, stocké dans un fichier de
  213. l'arborescence des sources de Guix, il peut être testé avec la commande
  214. @command{guix build} (@pxref{Invoquer guix build}). Par exemple, en
  215. supposant que le nouveau paquet s'appelle @code{gnew}, vous pouvez lancer
  216. cette commande depuis l'arborescence de construction de Guix (@pxref{Lancer Guix avant qu'il ne soit installé}) :
  217. @example
  218. ./pre-inst-env guix build gnew --keep-failed
  219. @end example
  220. Utiliser @code{--keep-failed} rend facile le débogage des échecs car il
  221. fournit l'accès à l'arborescence de construction qui a échouée. Une autre
  222. sous-commande utile pour le débogage est @code{--log-file}, pour accéder au
  223. journal de construction.
  224. Si le paquet n'est pas connu de la commande @command{guix}, il se peut que
  225. le fichier source ait une erreur de syntaxe, ou qu'il manque une clause
  226. @code{define-public} pour exporter la variable du paquet. Pour comprendre
  227. cela, vous pouvez charger le module depuis Guile pour avoir plus
  228. d'informations sur la véritable erreur :
  229. @example
  230. ./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
  231. @end example
  232. Une fois que votre paquet est correctement construit, envoyez-nous un
  233. correctif (@pxref{Contribuer}). Enfin, si vous avez besoin d'aide, nous
  234. serrons ravis de vous aider. Une fois que le correctif soumis est committé
  235. dans le dépôt Guix, le nouveau paquet est automatiquement construit sur les
  236. plate-formes supportées par @url{http://hydra.gnu.org/jobset/gnu/master,
  237. notre système d'intégration continue}.
  238. @cindex substitution
  239. On peut obtenir la nouvelle définition du paquet simplement en lançant
  240. @command{guix pull} (@pxref{Invoquer guix pull}). Lorsque
  241. @code{@value{SUBSTITUTE-SERVER}} a fini de construire le paquet,
  242. l'installation du paquet y télécharge automatiquement les binaires
  243. (@pxref{Substituts}). La seule intervention humaine requise est pendant la
  244. revue et l'application du correctif.
  245. @menu
  246. * Liberté logiciel:: Ce que la distribution peut contenir.
  247. * Conventions de nommage:: Qu'est-ce qu'un bon nom ?
  248. * Numéros de version:: Lorsque le nom n'est pas suffisant.
  249. * Synopsis et descriptions:: Aider les utilisateurs à trouver le bon
  250. paquet.
  251. * Modules python:: Un peu de comédie anglaise.
  252. * Modules perl:: Petites perles.
  253. * Paquets java:: Pause café.
  254. * Polices de caractères:: À fond les fontes.
  255. @end menu
  256. @node Liberté logiciel
  257. @subsection Liberté logiciel
  258. @c ===========================================================================
  259. @c
  260. @c This file was generated with po4a. Translate the source file.
  261. @c
  262. @c ===========================================================================
  263. @c Adapted from http://www.gnu.org/philosophy/philosophy.html.
  264. @cindex logiciel libre
  265. Le système d'exploitation GNU a été développé pour que les utilisateurs
  266. puissent utiliser leur ordinateur en toute liberté. GNU est un
  267. @dfn{logiciel libre}, ce qui signifie que les utilisateur ont les
  268. @url{http://www.gnu.org/philosophy/free-sw.fr.html,quatre libertés
  269. essentielles} : exécuter le programmer, étudier et modifier le programme
  270. sous sa forme source, redistribuer des copies exactes et distribuer les
  271. versions modifiées. Les paquets qui se trouvent dans la distribution GNU ne
  272. fournissent que des logiciels qui respectent ces quatre libertés.
  273. En plus, la distribution GNU suit les
  274. @url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,recommandations
  275. pour les distributions systèmes libres}. Entre autres choses, ces
  276. recommandations rejettent les microgiciels non libres, les recommandations
  277. de logiciels non libres et discute des façon de gérer les marques et les
  278. brevets.
  279. Certaines sources amont autrement parfaitement libres contiennent une petite
  280. partie facultative qui viole les recommandations ci-dessus, par exemple car
  281. cette partie est du code non-libre. Lorsque cela arrive, les éléments en
  282. question sont supprimés avec des correctifs ou des bouts de codes appropriés
  283. dans la forme @code{origin} du paquet (@pxref{Définition des paquets}). De cette
  284. manière, @code{guix build --source} renvoie la source « libérée » plutôt que
  285. la source amont sans modification.
  286. @node Conventions de nommage
  287. @subsection Conventions de nommage
  288. @cindex nom du paquet
  289. Un paquet a en fait deux noms qui lui sont associés : d'abord il y a le nom
  290. de la @emph{variable Scheme}, celui qui suit @code{define-public}. Par ce
  291. nom, le paquet peut se faire connaître par le code Scheme, par exemple comme
  292. entrée d'un autre paquet. Deuxièmement, il y a la chaîne dans le champ
  293. @code{name} d'une définition de paquet. Ce nom est utilisé par les
  294. commandes de gestion des paquets comme @command{guix package} et
  295. @command{guix build}.
  296. Les deux sont habituellement les mêmes et correspondent à la conversion en
  297. minuscule du nom du projet choisi en amont, où les underscores sont
  298. remplacés par des tirets. Par exemple, GNUnet est disponible en tant que
  299. @code{gnunet} et SDL_net en tant que @code{sdl-net}.
  300. Nous n'ajoutons pas de préfixe @code{lib} au bibliothèques de paquets, à
  301. 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
  302. modules pour les langages Python et Perl.
  303. Les noms de paquets de polices sont gérés différemment, @pxref{Polices de caractères}.
  304. @node Numéros de version
  305. @subsection Numéros de version
  306. @cindex version du paquet
  307. Nous n'incluons en général que la dernière version d'un projet de logiciel
  308. libre donné. Mais parfois, par exemple pour des versions incompatibles de
  309. bibliothèques, deux (ou plus) versions du même paquet sont requises. Elles
  310. ont besoin d'un nom de variable Scheme différent. Nous utilisons le nom
  311. défini dans @ref{Conventions de nommage} pour la version la plus récente ; les
  312. versions précédentes utilisent le même nom, suffixé par @code{-} et le plus
  313. petit préfixe du numéro de version qui permet de distinguer deux versions.
  314. Le nom dans la définition du paquet est le même pour toutes les versions
  315. d'un paquet et ne contient pas de numéro de version.
  316. Par exemple, les version 2.24.20 et 3.9.12 de GTK+ peuvent être inclus de
  317. cette manière :
  318. @example
  319. (define-public gtk+
  320. (package
  321. (name "gtk+")
  322. (version "3.9.12")
  323. ...))
  324. (define-public gtk+-2
  325. (package
  326. (name "gtk+")
  327. (version "2.24.20")
  328. ...))
  329. @end example
  330. Si nous voulons aussi GTK+ 3.8.2, cela serait inclus de cette manière :
  331. @example
  332. (define-public gtk+-3.8
  333. (package
  334. (name "gtk+")
  335. (version "3.8.2")
  336. ...))
  337. @end example
  338. @c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
  339. @c for a discussion of what follows.
  340. @cindex numéro de version, pour les instantanés des systèmes de contrôle de version
  341. Parfois, nous incluons des paquets provenant d'instantanés de systèmes de
  342. contrôle de version (VCS) au lieu de versions publiées formellement. Cela
  343. devrait rester exceptionnel, car c'est le rôle des développeurs amont de
  344. spécifier quel est la version stable. Cependant, c'est parfois nécessaire.
  345. Donc, que faut-il mettre dans le champ @code{version} ?
  346. Clairement, nous devons rendre l'identifiant de commit de l'instantané du
  347. VCS visible dans la version, mais nous devons aussi nous assurer que la
  348. version augmente de manière monotone pour que @command{guix package
  349. --upgrade} puisse déterminer quelle version est la plus récente. Comme les
  350. identifiants de commits, notamment avec Git, n'augmentent pas, nous ajoutons
  351. un numéro de révision qui nous augmentons à chaque fois que nous mettons à
  352. jour vers un nouvel instantané. La chaîne qui en résulte ressemble à cela :
  353. @example
  354. 2.0.11-3.cabba9e
  355. ^ ^ ^
  356. | | `-- ID du commit en amont
  357. | |
  358. | `--- révision du paquet Guix
  359. |
  360. dernière version en amont
  361. @end example
  362. C'est une bonne idée de tronquer les identifiants dans le champ
  363. @code{version} à disons 7 caractères. Cela évite un problème esthétique (en
  364. supposant que l'esthétique ait un rôle à jouer ici) et des problèmes avec
  365. les limites de l'OS comme la longueur maximale d'un shebang (127 octets pour
  366. le noyau Linux). Il vaut mieux utilise l'identifiant de commit complet dans
  367. @code{origin} cependant, pour éviter les ambiguïtés. Une définition de
  368. paquet peut ressembler à ceci :
  369. @example
  370. (define my-package
  371. (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
  372. (revision "1")) ;révision du paquet Guix
  373. (package
  374. (version (git-version "0.9" revision commit))
  375. (source (origin
  376. (method git-fetch)
  377. (uri (git-reference
  378. (url "git://example.org/my-package.git")
  379. (commit commit)))
  380. (sha256 (base32 "1mbikn@dots{}"))
  381. (file-name (git-file-name name version))))
  382. ;; @dots{}
  383. )))
  384. @end example
  385. @node Synopsis et descriptions
  386. @subsection Synopsis et descriptions
  387. @cindex description du paquet
  388. @cindex résumé du paquet
  389. Comme nous l'avons vu avant, chaque paquet dans GNU@tie{}Guix contient un
  390. résumé et une description (@pxref{Définition des paquets}). Les résumés et les
  391. descriptions sont importants : ce sont eux que recherche @command{guix
  392. package --search}, et c'est une source d'informations cruciale pour aider
  393. les utilisateurs à déterminer si un paquet donner correspond à leurs
  394. besoins. En conséquence, les mainteneurs doivent prêter attention à leur
  395. contenu.
  396. Les résumés doivent commencer par une lettre capitale et ne doit pas finir
  397. par un point. Ils ne doivent pas commencer par « a » ou « the » (« un » ou
  398. « le/la »), ce qui n'apporte généralement rien ; par exemple, préférez «
  399. File-frobbing tool » (« Outil de frobage de fichier ») à « A tool that frobs
  400. file » (« Un outil qui frobe les fichiers »). Le résumé devrait dire ce que
  401. le paquet est — p.@: ex.@: « Utilitaire du cœur de GNU (fichier, text,
  402. shell) » — ou ce à quoi il sert — p.@: ex.@: le résumé de grep est « Affiche
  403. des lignes correspondant à un motif ».
  404. Gardez à l'esprit que le résumé doit avoir un sens pour une large audience.
  405. Par exemple « Manipulation d'alignements au format SAM » peut avoir du sens
  406. pour un bioinformaticien chevronné, mais n'aidera pas ou pourra perdre une
  407. audience de non-spécialistes. C'est une bonne idée de créer un résumé qui
  408. donne une idée du domaine d'application du paquet. Dans cet exemple, cela
  409. donnerait « Manipulation d'alignements de séquences de nucléotides », ce qui
  410. devrait donner une meilleure idée à l'utilisateur pour savoir si c'est ce
  411. qu'il recherche.
  412. Les descriptions devraient faire entre cinq et dix lignes. Utilisez des
  413. phrases complètes, et évitez d'utiliser des acronymes sans les introduire
  414. d'abord. Évitez les phrases marketings comme « world-leading », «
  415. industrial-strength » et « next-generation » et évitez les superlatifs comme
  416. « the most advanced » — ils ne sont pas utiles pour les utilisateurs qui
  417. cherchent un paquet et semblent même un peu suspects. À la place, essayez
  418. d'être factuels, en mentionnant les cas d'utilisation et les
  419. fonctionnalités.
  420. @cindex balisage texinfo, dans les descriptions de paquets
  421. Les descriptions peuvent inclure du balisage Texinfo, ce qui est utile pour
  422. introduire des ornements comme @code{@@code} ou @code{@@dfn}, des listes à
  423. points ou des hyperliens (@pxref{Overview,,, texinfo, GNU Texinfo}).
  424. Cependant soyez prudents lorsque vous utilisez certains symboles, par
  425. exemple @samp{@@} et les accolades qui sont les caractères spéciaux de base
  426. en Texinfo (@pxref{Special Characters,,, texinfo, GNU Texinfo}). Les
  427. interfaces utilisateurs comme @command{guix package --show} prennent en
  428. charge le rendu.
  429. Les résumés et les descriptions sont traduits par des volontaires
  430. @uref{http://translationproject.org/domain/guix-packages.html, sur le projet
  431. de traduction} pour que le plus d'utilisateurs possible puissent les lire
  432. dans leur langue natale. Les interfaces utilisateurs les recherchent et les
  433. affichent dans la langue spécifiée par le paramètre de régionalisation
  434. actuel.
  435. Pour permettre à @command{xgettext} de les extraire comme des chaînes
  436. traduisibles, les résumés et les descriptions @emph{doivent être des chaînes
  437. litérales}. Cela signifie que vous ne pouvez pas utiliser
  438. @code{string-append} ou @code{format} pour construire ces chaînes :
  439. @lisp
  440. (package
  441. ;; @dots{}
  442. (synopsis "Ceci est traduisible")
  443. (description (string-append "Ceci n'est " "*pas*" " traduisible.")))
  444. @end lisp
  445. La traduction demande beaucoup de travail, donc en tant que packageur,
  446. faîtes encore plus attention à vos résumés et descriptions car chaque
  447. changement peut demander d'autant plus de travail de la part des
  448. traducteurs. Pour les aider, il est possible de donner des recommandations
  449. ou des instructions qu'ils pourront voir en insérant des commentaires
  450. spéciaux comme ceci (@pxref{xgettext Invocation,,, gettext, GNU Gettext}) :
  451. @example
  452. ;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
  453. (description "ARandR is designed to provide a simple visual front end
  454. for the X11 resize-and-rotate (RandR) extension. @dots{}")
  455. @end example
  456. @node Modules python
  457. @subsection Modules python
  458. @cindex python
  459. Nous incluons actuellement Python 2 et Python 3, sous les noms de variables
  460. 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
  461. langages de programmation, il semble désirable que le nom d'un paquet pour
  462. un module Python contienne le mot @code{python}.
  463. Certains modules ne sont compatibles qu'avec une version de Python, d'autres
  464. avec les deux. Si le paquet Foo ne compile qu'avec Ptyhon 3, on le nomme
  465. @code{python-foo} ; s'il ne compile qu'avec Python 2, on le nome
  466. @code{python2-foo}. S'il est compatible avec les deux versions, nous créons
  467. deux paquets avec les noms correspondant.
  468. Si un projet contient déjà le mot @code{python}, on l'enlève, par exemple le
  469. module python-dateutil est packagé sous les noms @code{python-dateutil} et
  470. @code{python2-dateutil}. Si le nom du projet commence par @code{py} (p.@:
  471. ex.@: @code{pytz}), on le garde et on le préfixe comme décrit ci-dessus.
  472. @subsubsection Spécifier les dépendances
  473. @cindex entrées, pour les paquets Python
  474. Les informations de dépendances pour les paquets Python se trouvent
  475. généralement dans l'arborescence des source du paquet, avec plus ou moins de
  476. précision : dans le fichier @file{setup.py}, dans @file{requirements.txt} ou
  477. dans @file{tox.ini}.
  478. Votre mission, lorsque vous écrivez une recette pour un paquet Python, est
  479. de faire correspondre ces dépendances au bon type « d'entrée »
  480. (@pxref{Référence des paquets, inputs}). Bien que l'importeur @code{pypi} fasse
  481. du bon boulot (@pxref{Invoquer guix import}), vous devriez vérifier la liste
  482. suivant pour déterminer où va telle dépendance.
  483. @itemize
  484. @item
  485. Nous empaquetons Python 2 avec @code{setuptools} et @code{pip} installé
  486. comme Python 3.4 par défaut. Ainsi, vous n'avez pas à spécifié ces
  487. entrées. @command{guix lint} vous avertira si vous faîtes cela.
  488. @item
  489. Les dépendances Python requises à l'exécutions vont dans
  490. @code{propagated-inputs}. Elles sont typiquement définies dans le mot-clef
  491. @code{install_requires} dans @file{setup.py} ou dans le fichier
  492. @file{requirements.txt}.
  493. @item
  494. Les paquets Python requis uniquement à la construction — p.@: ex.@: ceux
  495. listés dans le mot-clef @code{setup_requires} de @file{setup.py} — ou
  496. seulement pour les tests — p.@: ex.@: ceux dans @code{tests_require} — vont
  497. dans @code{native-inputs}. La raison est qu'ils n'ont pas besoin d'être
  498. propagés car ils ne sont pas requis à l'exécution et dans le cas d'une
  499. compilation croisée, c'est l'entrée « native » qu'il nous faut.
  500. Les cadriciels de tests @code{pytest}, @code{mock} et @code{nose} sont des
  501. exemples. Bien sûr si l'un de ces paquets est aussi requis à l'exécution,
  502. il doit aller dans @code{propagated-inputs}.
  503. @item
  504. Tout ce qui ne tombe pas dans les catégories précédentes va dans
  505. @code{inputs}, par exemple des programmes pour des bibliothèques C requises
  506. pour construire des paquets Python avec des extensions C.
  507. @item
  508. Si un paquet Python a des dépendances facultatives (@code{extras_require}),
  509. c'est à vous de décider de les ajouter ou non, en fonction du ratio entre
  510. utilité et complexité (@pxref{Envoyer des correctifs, @command{guix size}}).
  511. @end itemize
  512. @node Modules perl
  513. @subsection Modules perl
  514. @cindex perl
  515. Les programmes Perl utiles en soit sont nommés comme les autres paquets,
  516. avec le nom amont en minuscule. Pour les paquets Perl contenant une seule
  517. classe, nous utilisons le nom de la classe en minuscule, en remplaçant les
  518. occurrences de @code{::} par des tirets et en préfixant le tout par
  519. @code{perl-}. Donc la classe @code{XML::Parser} devient
  520. @code{perl-xml-parser}. Les modules contenant plusieurs classes gardent
  521. leur nom amont en minuscule et sont aussi préfixés par @code{perl-}. Ces
  522. modules tendent à avoir le mot @code{perl} quelque part dans leur nom, que
  523. nous supprimons en faveur du préfixe. Par exemple, @code{libwww-perl}
  524. devient @code{perl-libwww}.
  525. @node Paquets java
  526. @subsection Paquets java
  527. @cindex java
  528. Le programmes Java utiles en soit sont nommés comme les autres paquets, avec
  529. le nom amont en minuscule.
  530. Pour éviter les confusions et les problèmes de nom avec d'autres langages de
  531. programmation, il est désirable que le nom d'un paquet Java soit préfixé par
  532. @code{java-}. Si un projet contient déjà le mot @code{java}, nous le
  533. supprimons, par exemple le paquet @code{ngsjava} est empaqueté sous le nom
  534. @code{java-ngs}.
  535. Pour les paquets java contenant une seul classe ou une petite hiérarchie de
  536. classes, nous utilisons le nom de la classe en minuscule, en remplaçant les
  537. occurrences de @code{.} par des tirets et en préfixant le tout par
  538. @code{java-}. Donc la classe @code{apache.commons.cli} devient
  539. @code{java-apache-commons-cli}.
  540. @node Polices de caractères
  541. @subsection Polices de caractères
  542. @cindex polices
  543. Pour les polices qui n esont en général par installées par un utilisateurs
  544. pour du traitement de texte, ou qui sont distribuées en tant que partie d'un
  545. paquet logiciel plus gros, nous nous appuyons sur les règles générales pour
  546. les logiciels ; par exemple, cela s'applique aux polices livrées avec le
  547. système X.Org ou les polices qui font partie de TeX Live.
  548. Pour rendre plus facile la recherche par l'utilisateur, les noms des autres
  549. paquets contenant seulement des polices sont construits ainsi,
  550. indépendamment du nom du paquet en amont.
  551. Le nom d'un paquet contenant une unique famille de polices commence par
  552. @code{font-} ; il est suivi du nom du fondeur et d'un tiret @code{-} si le
  553. fondeur est connu, et du nom de la police, dont les espaces sont remplacés
  554. par des tirets (et comme d'habitude, toutes les lettres majuscules sont
  555. transformées en minuscules). Par exemple, la famille de polices Gentium de
  556. SIL est empaqueté sous le nom @code{font-sil-gentium}.
  557. Pour un paquet contenant plusieurs familles de polices, le nom de la
  558. collection est utilisée à la place du nom de la famille. Par exemple les
  559. polices Liberation consistent en trois familles, Liberation Sans, Liberation
  560. Serif et Liberation Mono. Elles pourraient être empaquetées séparément sous
  561. les noms @code{font-liberation-sans} etc, mais comme elles sont distribuées
  562. ensemble sous un nom commun, nous préférons les empaqueter ensemble en tant
  563. que @code{font-liberation}.
  564. Dans le cas où plusieurs formats de la même famille ou collection sont
  565. empaquetés séparément, une forme courte du format, préfixé d'un tiret est
  566. ajouté au nom du paquet. Nous utilisont @code{-ttf} pour les polices
  567. TrueType, @code{-otf} pour les polices OpenType et @code{-type1} pour les
  568. polices Type 1 de PostScript.
  569. @node Style de code
  570. @section Style de code
  571. En général notre code suit le Standard de Code GNU (@pxref{Top,,, standards,
  572. GNU Coding Standards}). Cependant, il ne parle pas beaucoup de Scheme, donc
  573. voici quelques règles supplémentaires.
  574. @menu
  575. * Paradigme de programmation:: Comment composer vos éléments.
  576. * Modules:: Où stocker votre code ?
  577. * Types de données et reconnaissance de motif:: Implémenter des
  578. structures de données.
  579. * Formatage du code:: Conventions d'écriture.
  580. @end menu
  581. @node Paradigme de programmation
  582. @subsection Paradigme de programmation
  583. Le code Scheme dans Guix est écrit dans un style purement fonctionnel. Le
  584. code qui s'occupe des entrées-sorties est une exception ainsi que les
  585. procédures qui implémentent des concepts bas-niveau comme la procédure
  586. @code{memoize}.
  587. @node Modules
  588. @subsection Modules
  589. Les modules Guile qui sont sensés être utilisés du côté de la construction
  590. doivent se trouver dans l'espace de nom @code{(guix build @dots{})}. Ils ne
  591. doivent pas se référer à d'autres modules Guix ou GNU@. Cependant il est
  592. correct pour un module « côté hôte » de dépendre d'un module coté
  593. construction.
  594. Les modules qui s'occupent du système GNU général devraient se trouver dans
  595. l'espace de nom @code{(gnu @dots{})} plutôt que @code{(guix @dots{})}.
  596. @node Types de données et reconnaissance de motif
  597. @subsection Types de données et reconnaissance de motif
  598. La tendance en Lisp classique est d'utiliser des listes pour tout
  599. représenter et de naviguer dedans « à la main ( avec @code{car}, @code{cdr},
  600. @code{cadr} et compagnie. Il y a plusieurs problèmes avec ce style,
  601. notamment le fait qu'il soit dur à lire, source d'erreur et un obstacle aux
  602. rapports d'erreur bien typés.
  603. Le code de Guix devrait définir des types de données appropriées (par
  604. exemple, avec @code{define-record-type*}) plutôt que d'abuser des listes.
  605. En plus, il devrait utiliser la recherche de motifs, via le module Guile
  606. @code{(ice-9 match)}, surtout pour rechercher dans des listes.
  607. @node Formatage du code
  608. @subsection Formatage du code
  609. @cindex formater le code
  610. @cindex style de code
  611. Lorsque nous écrivons du code Scheme, nous suivons la sagesse commune aux
  612. programmeurs Scheme. En général, nous suivons les
  613. @url{http://mumble.net/~campbell/scheme/style.txt, règles de style de
  614. Riastradh}. Ce document décrit aussi les conventions utilisées dans le code
  615. de Guile. Il est bien pensé et bien écrit, alors n'hésitez pas à le lire.
  616. Certaines formes spéciales introduites dans Guix comme la macro
  617. @code{substitute*} ont des règles d'indentation spécifiques. Elles sont
  618. définies dans le fichier @file{.dir-locals.el} qu'Emacs utilise
  619. automatiquement. Remarquez aussi qu'Emacs-Guix fournit le mode
  620. @code{guix-devel-mode} qui indente et colore le code Guix correctement
  621. (@pxref{Développement,,, emacs-guix, The Emacs-Guix Reference Manual}).
  622. @cindex indentation, du code
  623. @cindex formatage, du code
  624. Si vous n'utilisez pas Emacs, assurez-vous que votre éditeur connaisse ces
  625. règles. Pour indenter automatiquement une définition de paquet, vous pouvez
  626. aussi lancer :
  627. @example
  628. ./etc/indent-code.el gnu/packages/@var{file}.scm @var{package}
  629. @end example
  630. @noindent
  631. Cela indente automatiquement la définition de @var{package} dans
  632. @file{gnu/packages/@var{file}.scm} en lançant Emacs en mode commande. Pour
  633. indenter un fichier complet, n'indiquez pas de second argument :
  634. @example
  635. ./etc/indent-code.el gnu/services/@var{file}.scm
  636. @end example
  637. @cindex Vim, édition de code Scheme
  638. Si vous éditez du code avec Vim, nous recommandons de lancer @code{:set
  639. autoindent} pour que votre code soit automatiquement indenté au moment où
  640. vous l'entrez. En plus,
  641. @uref{https://www.vim.org/scripts/script.php?script_id=3998,
  642. @code{paredit.vim}} peut vous aider à gérer toutes ces parenthèses.
  643. Nous demandons que toutes les procédure de premier niveau contiennent une
  644. chaîne de documentation. Ce prérequis peut être relâché pour les procédures
  645. privées simples dans l'espace de nom @code{(guix build @dots{})} cependant.
  646. Les procédures ne devraient pas avoir plus de quatre paramètres
  647. positionnés. Utilisez des paramètres par mot-clefs pour les procédures qui
  648. prennent plus de quatre paramètres.
  649. @node Envoyer des correctifs
  650. @section Envoyer des correctifs
  651. Le développement se fait avec le système de contrôle de version Git. Ainsi,
  652. l'accès au dépôt n'est pas strictement nécessaire. Nous accueillons les
  653. contributions sous forme de correctifs produits par @code{git format-patch}
  654. envoyés sur la liste de diffusion @email{guix-patches@@gnu.org}.
  655. Cette liste de diffusion est gérée par une instance Debbugs accessible à
  656. l'adresse @uref{https://bugs.gnu.org/guix-patches}, qui nous permet de
  657. suivre les soumissions. Chaque message envoyé à cette liste se voit
  658. attribuer un numéro de suivi ; les gens peuvent ensuite répondre à cette
  659. soumission en envoyant un courriel à @code{@var{NNN}@@debbugs.gnu.org}, où
  660. @var{NNN} est le numéro de suivi (@pxref{Envoyer une série de correctifs}).
  661. Veuillez écrire les messages de commit dans le format ChangeLog
  662. (@pxref{Change Logs,,, standards, GNU Coding Standards}) ; vous pouvez
  663. regarder l'historique des commits pour trouver des exemples.
  664. Avant de soumettre un correctif qui ajoute ou modifie la définition d'un
  665. paquet, veuillez vérifier cette check-list :
  666. @enumerate
  667. @item
  668. Si les auteurs du paquet logiciel fournissent une signature cryptographique
  669. pour l'archive, faîtes un effort pour vérifier l'authenticité de l'archive.
  670. Pour un fichier de signature GPG détaché, cela se fait avec la commande
  671. @code{gpg --verify}.
  672. @item
  673. Prenez un peu de temps pour fournir un synopsis et une description adéquats
  674. pour le paquet. Voir @xref{Synopsis et descriptions} pour quelques lignes
  675. directrices.
  676. @item
  677. Lancez @code{guix lint @var{paquet}}, où @var{paquet} est le nom du nouveau
  678. paquet ou du paquet modifié, et corrigez les erreurs qu'il rapporte
  679. (@pxref{Invoquer guix lint}).
  680. @item
  681. Assurez-vous que le paquet se construise sur votre plate-forme avec
  682. @code{guix build @var{paquet}}.
  683. @item
  684. Nous vous recommandons aussi d'essayer de construire le paquet sur les
  685. autres plate-formes prises en charge. Comme vous n'avez pas forcément accès
  686. aux plate-formes matérielles, nous vous recommandons d'utiliser le
  687. @code{qemu-binfmt-service-type} pour les émuler. Pour cela, ajoutez le
  688. service suivant à la liste des services dans votre configuration de système
  689. d'exploitation :
  690. @example
  691. (service qemu-binfmt-service-type
  692. (qemu-binfmt-configuration
  693. (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))
  694. (guix-support? #t)))
  695. @end example
  696. Puis reconfigurez votre système.
  697. Vous pourrez ensuite construire les paquets pour différentes plate-formes en
  698. spécifiant l'option @code{--system}. Par exemple pour construire le paquet
  699. « hello » pour les architectures armhf, aarch64 ou mips64, vous devrez
  700. lancer les commandes suivantes, respectivement :
  701. @example
  702. guix build --system=armhf-linux --rounds=2 hello
  703. guix build --system=aarch64-linux --rounds=2 hello
  704. guix build --system=mips64el-linux --rounds=2 hello
  705. @end example
  706. @item
  707. @cindex construction groupée
  708. Assurez-vous que le paquet n'utilise pas de copie groupée d'un logiciel déjà
  709. disponible dans un paquet séparé.
  710. Parfois, les paquets incluent des copie du code source de leurs dépendances
  711. pour le confort de leurs utilisateurs. Cependant, en tant que distribution,
  712. nous voulons nous assurer que ces paquets utilisent bien les copient que
  713. nous avons déjà dans la distribution si elles existent. Cela améliore
  714. l'utilisation des ressources (la dépendance n'est construite et stockée
  715. qu'une seule fois) et permet à la distribution de faire des changements
  716. transversaux comme appliquer des correctifs de sécurité pour un paquet donné
  717. depuis un unique emplacement et qu'ils affectent tout le système, ce
  718. qu'empêchent les copies groupées.
  719. @item
  720. Regardez le profil rapporté par @command{guix size} (@pxref{Invoquer guix size}). Cela vous permettra de remarquer des références à d'autres paquets
  721. qui ont été retenus sans que vous vous y attendiez. Il peut aussi aider à
  722. déterminer s'il faut découper le paquet (@pxref{Des paquets avec plusieurs
  723. résultats}) et quelles dépendances facultatives utiliser. En particulier,
  724. évitez d'ajouter @code{texlive} en dépendance : à cause de sa taille
  725. extrême, utilisez @code{texlive-tiny} ou @code{texlive-union} à la place.
  726. @item
  727. Pour les changements important, vérifiez que les paquets qui en dépendent
  728. (s'ils existent) ne sont pas affectés par le changement ; @code{guix refresh
  729. --list-dependant @var{paquet}} vous aidera (@pxref{Invoquer guix refresh}).
  730. @c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
  731. @cindex stratégie de branche
  732. @cindex stratégie de planification des reconstructions
  733. Suivant le nombre de paquets dépendants et donc le nombre de reconstruction
  734. induites, les commits vont vers des branches différentes, suivant ces
  735. principes :
  736. @table @asis
  737. @item 300 paquets dépendants ou moins
  738. branche @code{master} (changements non-disruptifs).
  739. @item entre 300 et 1 200 paquets dépendants
  740. branche @code{staging} (changements non-disruptifs). Cette branche devrait
  741. être fusionnées dans @code{master} tous les 3 semaines. Les changements par
  742. thèmes (par exemple une mise à jour de la pile GNOME) peuvent aller dans une
  743. branche spécifique (disons, @code{gnome-updates}).
  744. @item plus de 1 200 paquets dépendants
  745. branche @code{core-updates} (peut inclure des changements majeurs et
  746. potentiellement disruptifs). Cette branche devrait être fusionnée dans
  747. @code{master} tous les 2,5 mois environ.
  748. @end table
  749. Toutes ces branches sont @uref{https://hydra.gnu.org/project/gnu, gérées par
  750. notre ferme de construction} et fusionnées dans @code{master} une fois que
  751. tout a été construit correctement. Cela nous permet de corriger des
  752. problèmes avant qu'ils n'atteignent les utilisateurs et réduit la fenêtre
  753. pendant laquelle les binaires pré-construits ne sont pas disponibles.
  754. @c TODO: It would be good with badges on the website that tracks these
  755. @c branches. Or maybe even a status page.
  756. Généralement les autres branches que @code{master} sont considérées comme
  757. @emph{gelées} s'il y a eu une évaluation récente ou qu'il y a une branche
  758. @code{-next} correspondante. Demandez sur la liste de diffusion ou sur IRC
  759. si vous n'êtes pas sûr de savoir où pousser votre correctif.
  760. @item
  761. @cindex déterminisme, du processus de construction
  762. @cindex construction reproductibles, vérification
  763. Vérifiez si le processus de construction du paquet est déterministe. Cela
  764. signifie typiquement vérifier qu'une construction indépendante du paquet
  765. renvoie exactement le même résultat que vous avez obtenu, bit à bit.
  766. Une manière simple de le faire est de reconstruire le paquet plusieurs fois
  767. à la suite sur votre machine (@pxref{Invoquer guix build}) :
  768. @example
  769. guix build --rounds=2 mon-paquet
  770. @end example
  771. Cela est suffisant pour trouver une classe de non-déterminisme commune,
  772. comme l'horodatage ou des sorties générées aléatoirement dans le résultat de
  773. la construction.
  774. Une autre option consiste à utiliser @command{guix challenge}
  775. (@pxref{Invoquer guix challenge}). Vous pouvez lancer la commande une fois
  776. que les paquets ont été committés et construits par
  777. @code{@value{SUBSTITUTE-SERVER}} pour vérifier s'il obtient le même résultat
  778. que vous. Mieux encore : trouvez une autre machine qui peut le construire
  779. et lancez @command{guix publish}. Puisque la machine distante est sûrement
  780. différente de la vôtre, cela peut trouver des problèmes de non-déterminisme
  781. liés au matériel — par exemple utiliser une extension du jeu d'instruction —
  782. ou du noyau du système d'exploitation — par exemple se reposer sur
  783. @code{uname} ou les fichiers de @file{/proc}.
  784. @item
  785. Lorsque vous écrivez de la documentation, utilisez une formulation au genre
  786. neutre lorsque vous vous référez à des personnes, comme le
  787. @uref{https://fr.wikipedia.org/wiki/They_singulier, ``they''@comma{}
  788. ``their''@comma{} ``them'' singulier} (en anglais).
  789. @item
  790. Vérifiez que votre correctif contienne seulement un ensemble de changements
  791. liés. Grouper des changements non liés ensemble rend la revue plus
  792. difficile et plus lente.
  793. Ajouter plusieurs paquet ou une mise à jour d'un paquet avec des corrections
  794. dans ce paquet sont des exemples de changements sans rapport.
  795. @item
  796. Suivez nos règles de formatage de code, éventuellement en lançant le script
  797. @command{et/indent-code.el} pour le faire automatiquement (@pxref{Formatage
  798. du code}).
  799. @item
  800. 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
  801. exemple, les archives GitHub ne sont pas nécessairement identiques d'une
  802. génération à la suivante, donc il vaut mieux dans ce cas cloner le dépôt.
  803. N'utilisez pas le champ @command{name} dans l'URL : ce n'est pas très utile
  804. et si le nom change, l'URL sera probablement erronée.
  805. @end enumerate
  806. Lorsque vous envoyez un correctif à la liste de diffusion, utilisez
  807. @samp{[PATCH] @dots{}} comme sujet. Vous pouvez utiliser votre client de
  808. courriel ou la commande @command{git send-email} (@pxref{Envoyer une série
  809. de correctifs}). Nous préférons recevoir des correctifs en texte brut, soit
  810. en ligne, soit en pièce-jointe MIME@. Nous vous conseillons de faire
  811. attention si votre client de courriel change par exemple les retours à la
  812. ligne ou l'indentation, ce qui peut casser les correctifs.
  813. Lorsqu'un bogue est résolu, veuillez fermer le fil en envoyant un courriel à
  814. @email{@var{NNN}-done@@debbugs.gnu.org}.
  815. @unnumberedsubsec Envoyer une série de correctifs
  816. @anchor{Envoyer une série de correctifs}
  817. @cindex série de correctifs
  818. @cindex @code{git send-email}
  819. @cindex @code{git-send-email}
  820. @c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
  821. Lorsque vous envoyez une série de correctifs (p.@@:: ex.@: avec @code{git
  822. send-email}), envoyez d'abord une premier message à
  823. @email{guix-patches@@gnu.org} puis envoyez le reste des correctifs à
  824. @email{@var{NNN}@@debbugs.gnu.org} pour vous assurer qu'ils seront groupés
  825. ensemble. Voyez @uref{https://debbugs.gnu.org/Advanced.html, la
  826. documentation de Debbugs} pour plus d'informations.