Commit | Line | Data |
---|---|---|
bf5c74e7 JL |
1 | @node Contribuer |
2 | @chapter Contribuer | |
3 | ||
4 | Ce projet est un effort coopératif et nous avons besoin de votre aide pour | |
5 | le faire grandir ! Contactez-nous sur @email{guix-devel@@gnu.org} et | |
6 | @code{#guix} sur le réseau IRC Freenode. Nous accueillons les idées, les | |
7 | rapports de bogues, les correctifs et tout ce qui pourrait aider le | |
8 | projet. Nous apprécions particulièrement toute aide sur la création de | |
9 | paquets (@pxref{Consignes d'empaquetage}). | |
10 | ||
11 | @cindex code de conduite, des contributeurs | |
12 | @cindex convention de contribution | |
13 | Nous souhaitons fournir un environnement chaleureux, amical et sans | |
14 | harcèlement pour que tout le monde puisse contribuer au mieux de ses | |
15 | capacités. Pour cela notre projet a une « Convention de contribution » | |
16 | adaptée de @url{http://contributor-covenant.org/}. Vous pouvez trouver une | |
17 | version locale dans le fichier @file{CODE-OF-CONDUCT} dans l'arborescence | |
18 | des sources. | |
19 | ||
20 | Les contributeurs n'ont pas besoin d'utiliser leur nom légal dans leurs | |
21 | correctifs et leurs communications en ligne ; ils peuvent utiliser n'importe | |
22 | quel nom ou pseudonyme de leur choix. | |
23 | ||
24 | @menu | |
25 | * Construire depuis Git:: The latest and greatest. | |
26 | * Lancer Guix avant qu'il ne soit installé:: Astuces pour les hackers. | |
27 | * La configuration parfaite:: Les bons outils. | |
28 | * Style de code:: Hygiène du contributeur. | |
29 | * Envoyer des correctifs:: Partager votre travail. | |
30 | @end menu | |
31 | ||
32 | @node Construire depuis Git | |
33 | @section Construire depuis Git | |
34 | ||
35 | Si vous souhaitez travailler sur Guix lui-même, il est recommandé d'utiliser | |
36 | la dernière version du dépôt Git : | |
37 | ||
38 | @example | |
39 | git clone https://git.savannah.gnu.org/git/guix.git | |
40 | @end example | |
41 | ||
42 | Lors de la construction de Guix depuis un extrait, les paquets suivants sont | |
43 | requis en plus de ceux mentionnés dans les instructions d'installation | |
44 | (@pxref{Prérequis}). | |
45 | ||
46 | @itemize | |
47 | @item @url{http://gnu.org/software/autoconf/, GNU Autoconf}; | |
48 | @item @url{http://gnu.org/software/automake/, GNU Automake}; | |
49 | @item @url{http://gnu.org/software/gettext/, GNU Gettext}; | |
50 | @item @url{http://gnu.org/software/texinfo/, GNU Texinfo}; | |
51 | @item @url{http://www.graphviz.org/, Graphviz}; | |
52 | @item @url{http://www.gnu.org/software/help2man/, GNU Help2man (facultatif)}. | |
53 | @end itemize | |
54 | ||
55 | La manière la plus simple de configurer un environnement de développement | |
56 | pour Guix est, bien sûr, d'utiliser Guix ! La commande suivante démarre un | |
57 | nouveau shell où toutes les dépendances et les variables d'environnements | |
58 | appropriées sont configurés pour travailler sur Guix : | |
59 | ||
60 | @example | |
61 | guix environment guix | |
62 | @end example | |
63 | ||
64 | @xref{Invoquer guix environment}, pour plus d'information sur cette | |
65 | commande. On peut ajouter des dépendances supplémentaires avec | |
66 | @option{--ad-hoc} : | |
67 | ||
68 | @example | |
69 | guix environment guix --ad-hoc help2man git strace | |
70 | @end example | |
71 | ||
72 | Lancez @command{./bootstrap} pour générer l'infrastructure du système de | |
73 | construction avec Autoconf et Automake. Si vous avez une erreur comme : | |
74 | ||
75 | @example | |
76 | configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES | |
77 | @end example | |
78 | ||
79 | @noindent | |
80 | cela signifie probablement qu'Autoconf n'a pas pu trouver @file{pkg.m4} qui | |
81 | est fournit par pkg-config. Assurez-vous que @file{pkg.m4} est | |
82 | disponible. C'est aussi vrai pour l'ensemble de macros de @file{guile.m4} | |
83 | fournies par Guile. Par exemple, si vous avez installé Automake dans | |
84 | @file{/usr/local}, il ne cherchera pas les fichiers @file{.m4} dans | |
85 | @file{/usr/share}. Dans ce case vous devez invoquer la commande suivante : | |
86 | ||
87 | @example | |
88 | export ACLOCAL_PATH=/usr/share/aclocal | |
89 | @end example | |
90 | ||
91 | @xref{Macro Search Path,,, automake, The GNU Automake Manual}, pour plus | |
92 | d'information. | |
93 | ||
94 | Ensuite, lancez @command{./configure} comme d'habitude. Assurez-vous de | |
95 | passer @code{--localstatedir=@var{directory}} où @var{directory} est la | |
96 | valeur @code{localstatedir} utilisée par votre installation actuelle | |
97 | (@pxref{Le dépôt} pour plus d'informations à ce propos). | |
98 | ||
99 | Finalement, vous devez invoquer @code{make check} pour lancer les tests | |
100 | (@pxref{Lancer la suite de tests}). Si quelque chose échoue, jetez un œil | |
101 | aux instructions d'installation (@pxref{Installation}) ou envoyez un message | |
102 | à la list @email{guix-devel@@gnu.org}. | |
103 | ||
104 | ||
105 | @node Lancer Guix avant qu'il ne soit installé | |
106 | @section Lancer Guix avant qu'il ne soit installé | |
107 | ||
108 | Pour garder un environnement de travail sain, il est utile de tester les | |
109 | changement localement sans les installer pour de vrai. Pour pouvoir | |
110 | distinguer votre rôle « d'utilisateur final » de celui parfois haut en | |
111 | couleur de « développeur ». | |
112 | ||
113 | Pour cela, tous les outils en ligne de commande sont utilisables même sans | |
114 | avoir lancé @code{make install}. Vous devez pour cela préfixer chaque | |
115 | commande par @command{./pre-inst-env} (le script @file{pre-inst-env} se | |
116 | trouve dans le répertoire de plus haut niveau de l'arborescence des sources | |
117 | de Guix) comme cela@footnote{L'option @option{-E} de @command{sudo} garantie | |
118 | que @code{GUILE_LOAD_PATH} est bien paramétré pour @command{guix-daemon} et | |
119 | les outils qu'il utilise puissent trouver les modules Guile dont ils ont | |
120 | besoin.} : | |
121 | ||
122 | @example | |
123 | $ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild | |
124 | $ ./pre-inst-env guix build hello | |
125 | @end example | |
126 | ||
127 | @noindent | |
128 | De même, pour une session Guile qui utilise les modules Guix : | |
129 | ||
130 | @example | |
131 | $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))' | |
132 | ||
133 | ;;; ("x86_64-linux") | |
134 | @end example | |
135 | ||
136 | @noindent | |
137 | @cindex REPL | |
138 | @cindex read-eval-print loop | |
139 | @dots{} et pour un REPL (@pxref{Using Guile Interactively,,, guile, Guile | |
140 | Reference Manual}) | |
141 | ||
142 | @example | |
143 | $ ./pre-inst-env guile | |
144 | scheme@@(guile-user)> ,use(guix) | |
145 | scheme@@(guile-user)> ,use(gnu) | |
146 | scheme@@(guile-user)> (define snakes | |
147 | (fold-packages | |
148 | (lambda (package lst) | |
149 | (if (string-prefix? "python" | |
150 | (package-name package)) | |
151 | (cons package lst) | |
152 | lst)) | |
153 | '())) | |
154 | scheme@@(guile-user)> (length snakes) | |
155 | $1 = 361 | |
156 | @end example | |
157 | ||
158 | Le script @command{pre-inst-env} paramètre toutes les variables | |
159 | d'environnement nécessaires, dont @env{PATH} et @env{GUILE_LOAD_PATH}. | |
160 | ||
161 | Remarquez que @command{./pre-inst-env guix pull} ne met @emph{pas} à jour | |
162 | l'arborescence des sources locale ; il met seulement à jour le lien | |
163 | symbolique @file{~/.config/guix/latest} (@pxref{Invoquer guix pull}). Lancez | |
164 | @command{git pull} à la place si vous voulez mettre à jour votre | |
165 | arborescence des sources locale@footnote{Si vous voulez paramétrer | |
166 | @command{guix} pour qu'il utilise votre dépôt Git, vous pouvez faire pointer | |
167 | le lien symbolique @file{~/.config/guix/latest} vers le répertoire contenant | |
168 | ce dépôt. Si vous le seul utilisateur du système, vous pouvez aussi | |
169 | considérer faire pointer le lien symbolique @file{/root/.config/guix/latest} | |
170 | vers @file{~/.config/guix/latest} ; comme ça root aura toujours la même | |
171 | commande @command{guix} que votre utilisateur}. | |
172 | ||
173 | ||
174 | @node La configuration parfaite | |
175 | @section La configuration parfaite | |
176 | ||
177 | La configuration parfaite pour travailler sur Guix est simplement la | |
178 | configuration parfaite pour travailler en Guile (@pxref{Using Guile in | |
179 | Emacs,,, guile, Guile Reference Manual}). Tout d'abord, vous avez besoin de | |
180 | mieux qu'un éditeur de texte, vous avez besoin de | |
181 | @url{http://www.gnu.org/software/emacs, Emacs}, amélioré par le superbe | |
182 | @url{http://nongnu.org/geiser/, Geiser}. | |
183 | ||
184 | Geiser permet le développement interactif et incrémental depuis Emacs : la | |
185 | compilation du code et son évaluation depuis les buffers, l'accès à la | |
186 | documentation en ligne (docstrings), la complétion sensible au contexte, | |
187 | @kbd{M-.} pour sauter à la définition d'un objet, un REPL pour tester votre | |
188 | code, et bien plus (@pxref{Introduction,,, geiser, Geiser User | |
189 | Manual}). Pour travailler confortablement sur Guix, assurez-vous de modifier | |
190 | le chemin de chargement de Guile pour qu'il trouve les fichiers source de | |
191 | votre dépôt : | |
192 | ||
193 | @lisp | |
194 | ;; @r{Si l'extrait est dans ~/src/guix.} | |
195 | (with-eval-after-load 'geiser-guile | |
196 | (add-to-list 'geiser-guile-load-path "~/src/guix")) | |
197 | @end lisp | |
198 | ||
199 | To actually edit the code, Emacs already has a neat Scheme mode. But in | |
200 | addition to that, you must not miss | |
201 | @url{http://www.emacswiki.org/emacs/ParEdit, Paredit}. It provides | |
202 | facilities to directly operate on the syntax tree, such as raising an | |
203 | s-expression or wrapping it, swallowing or rejecting the following | |
204 | s-expression, etc. | |
205 | ||
206 | @cindex extraits de code | |
207 | @cindex modèles | |
208 | @cindex réduire la quantité de code commun | |
209 | Nous fournissons aussi des modèles pour les messages de commit git communs | |
210 | et les définitions de paquets dans le répertoire @file{etc/snippets}. Ces | |
211 | modèles s'utilisent avec @url{http://joaotavora.github.io/yasnippet/, | |
212 | YASnippet} pour développer des chaînes courtes de déclenchement en extraits | |
213 | de texte interactifs. Vous pouvez ajouter le répertoire des modèles dans la | |
214 | variables @var{yas-snippet-dirs} d'Emacs. | |
215 | ||
216 | @lisp | |
217 | ;; @r{Si l'extrait est dans ~/src/guix.} | |
218 | (with-eval-after-load 'yasnippet | |
219 | (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets")) | |
220 | @end lisp | |
221 | ||
222 | Les extraits de messages de commit dépendent de @url{https://magit.vc/, | |
223 | Magit} pour afficher les fichiers sélectionnés. Lors de la modification d'un | |
224 | message de commit, tapez @code{add} suivi de @kbd{TAB} pour insérer un | |
225 | modèle de message de commit pour ajouter un paquet ; tapez @code{update} | |
226 | suivi de @kbd{TAB} pour insérer un modèle pour la mise à jour d'un paquet. | |
227 | ||
228 | L'extrait principal pour @code{scheme-mode} est lancé en tapant | |
229 | @code{package…} suivi par @kbd{TAB}. Cet extrait insère aussi la chaîne de | |
230 | déclenchement @code{origin…}, qui peut aussi être étendue. L'extrait | |
231 | @code{origin} lui-même peut aussi insérer des chaînes de déclenchement qui | |
232 | finissent sur @code{…}, qui peuvent aussi être étendues. | |
233 | ||
234 | ||
235 | @node Style de code | |
236 | @section Style de code | |
237 | ||
238 | En général notre code suit le Standard de Code GNU (@pxref{Top,,, standards, | |
239 | GNU Coding Standards}). Cependant, il ne parle pas beaucoup de Scheme, donc | |
240 | voici quelques règles supplémentaires. | |
241 | ||
242 | @menu | |
243 | * Paradigme de programmation:: Comment composer vos éléments. | |
244 | * Modules:: Où stocker votre code ? | |
245 | * Types de données et reconnaissance de motif:: Implémenter des | |
246 | structures de données. | |
247 | * Formatage du code:: Conventions d'écriture. | |
248 | @end menu | |
249 | ||
250 | @node Paradigme de programmation | |
251 | @subsection Paradigme de programmation | |
252 | ||
253 | Le code Scheme dans Guix est écrit dans un style purement fonctionnel. Le | |
254 | code qui s'occupe des entrées-sorties est une exception ainsi que les | |
255 | procédures qui implémentent des concepts bas-niveau comme la procédure | |
256 | @code{memoize}. | |
257 | ||
258 | @node Modules | |
259 | @subsection Modules | |
260 | ||
261 | Les modules Guile qui sont sensés être utilisés du côté de la construction | |
262 | doivent se trouver dans l'espace de nom @code{(guix build @dots{})}. Ils ne | |
263 | doivent pas se référer à d'autres modules Guix ou GNU. Cependant il est | |
264 | correct pour un module « côté hôte » de dépendre d'un module coté | |
265 | construction. | |
266 | ||
267 | Les modules qui s'occupent du système GNU général devraient se trouver dans | |
268 | l'espace de nom @code{(gnu @dots{})} plutôt que @code{(guix @dots{})}. | |
269 | ||
270 | @node Types de données et reconnaissance de motif | |
271 | @subsection Types de données et reconnaissance de motif | |
272 | ||
273 | La tendance en Lisp classique est d'utiliser des listes pour tout | |
274 | représenter et de naviguer dedans « à la main ( avec @code{car}, @code{cdr}, | |
275 | @code{cadr} et compagnie. Il y a plusieurs problèmes avec ce style, | |
276 | notamment le fait qu'il soit dur à lire, source d'erreur et un obstacle aux | |
277 | rapports d'erreur bien typés. | |
278 | ||
279 | Le code de Guix devrait définir des types de données appropriées (par | |
280 | exemple, avec @code{define-record-type*}) plutôt que d'abuser des listes. En | |
281 | plus, il devrait utiliser la recherche de motifs, via le module Guile | |
282 | @code{(ice-9 match)}, surtout pour rechercher dans des listes. | |
283 | ||
284 | @node Formatage du code | |
285 | @subsection Formatage du code | |
286 | ||
287 | @cindex formater le code | |
288 | @cindex style de code | |
289 | Lorsque nous écrivons du code Scheme, nous suivons la sagesse commune aux | |
290 | programmeurs Scheme. En général, nous suivons les | |
291 | @url{http://mumble.net/~campbell/scheme/style.txt, règles de style de | |
292 | Riastradh}. Ce document décrit aussi les conventions utilisées dans le code | |
293 | de Guile. Il est bien pensé et bien écrit, alors n'hésitez pas à le lire. | |
294 | ||
295 | Certaines formes spéciales introduites dans Guix comme la macro | |
296 | @code{substitute*} ont des règles d'indentation spécifiques. Elles sont | |
297 | définies dans le fichier @file{.dir-locals.el} qu'Emacs utilise | |
298 | automatiquement. Remarquez aussi qu'Emacs-Guix fournit le mode | |
299 | @code{guix-devel-mode} qui indente et colore le code Guix correctement | |
300 | (@pxref{Development,,, emacs-guix, The Emacs-Guix Reference Manual}). | |
301 | ||
302 | @cindex indentation, du code | |
303 | @cindex formatage, du code | |
304 | Si vous n'utilisez pas Emacs, assurez-vous que votre éditeur connaisse ces | |
305 | règles. Pour indenter automatiquement une définition de paquet, vous pouvez | |
306 | aussi lancer : | |
307 | ||
308 | @example | |
309 | ./etc/indent-code.el gnu/packages/@var{file}.scm @var{package} | |
310 | @end example | |
311 | ||
312 | @noindent | |
313 | Cela indente automatiquement la définition de @var{package} dans | |
314 | @file{gnu/packages/@var{file}.scm} en lançant Emacs en mode commande. Pour | |
315 | indenter un fichier complet, n'indiquez pas de second argument : | |
316 | ||
317 | @example | |
318 | ./etc/indent-code.el gnu/services/@var{file}.scm | |
319 | @end example | |
320 | ||
321 | Nous demandons que toutes les procédure de premier niveau contiennent une | |
322 | chaîne de documentation. Ce pré-requis peut être relâché pour les procédures | |
323 | privées simples dans l'espace de nom @code{(guix build @dots{})} cependant. | |
324 | ||
325 | Les procédures ne devraient pas avoir plus de quatre paramètres | |
326 | positionnés. Utilisez des paramètres par mot-clefs pour les procédures qui | |
327 | prennent plus de quatre paramètres. | |
328 | ||
329 | ||
330 | @node Envoyer des correctifs | |
331 | @section Envoyer des correctifs | |
332 | ||
333 | Le développement se fait avec le système de contrôle de version Git. Ainsi, | |
334 | l'accès au dépôt n'est pas strictement nécessaire. Nous accueillons les | |
335 | contributions sous forme de correctifs produits par @code{git format-patch} | |
336 | envoyés sur la liste de diffusion @email{guix-patches@@gnu.org}. | |
337 | ||
338 | Cette liste de diffusion est gérée par une instance Debbugs accessible à | |
339 | l'adresse @uref{https://bugs.gnu.org/guix-patches}, qui nous permet de | |
340 | suivre les soumissions. Chaque message envoyé à cette liste se voit | |
341 | attribuer un numéro de suivi ; les gens peuvent ensuite répondre à cette | |
342 | soumission en envoyant un courriel à @code{@var{NNN}@@debbugs.gnu.org}, où | |
343 | @var{NNN} est le numéro de suivi (@pxref{Envoyer une série de correctifs}). | |
344 | ||
345 | Veuillez écrire les messages de commit dans le format ChangeLog | |
346 | (@pxref{Change Logs,,, standards, GNU Coding Standards}) ; vous pouvez | |
347 | regarder l'historique des commits pour trouver des exemples. | |
348 | ||
349 | Avant de soumettre un correctif qui ajoute ou modifie la définition d'un | |
350 | paquet, veuillez vérifier cette check-list : | |
351 | ||
352 | @enumerate | |
353 | @item | |
354 | Si les auteurs du paquet logiciel fournissent une signature cryptographique | |
355 | pour l'archive, faîtes un effort pour vérifier l'authenticité de | |
356 | l'archive. Pour un fichier de signature GPG détaché, cela se fait avec la | |
357 | commande @code{gpg --verify}. | |
358 | ||
359 | @item | |
360 | Prenez un peu de temps pour fournir un synopsis et une description adéquats | |
361 | pour le paquet. Voir @xref{Synopsis et descriptions} pour quelques lignes | |
362 | directrices. | |
363 | ||
364 | @item | |
365 | Lancez @code{guix lint @var{paquet}}, où @var{paquet} est le nom du nouveau | |
366 | paquet ou du paquet modifié, et corrigez les erreurs qu'il rapporte | |
367 | (@pxref{Invoquer guix lint}). | |
368 | ||
369 | @item | |
370 | Assurez-vous que le paquet se construise sur votre plate-forme avec | |
371 | @code{guix build @var{paquet}}. | |
372 | ||
373 | @item | |
374 | @cindex construction groupée | |
375 | Assurez-vous que le paquet n'utilise pas de copie groupée d'un logiciel déjà | |
376 | disponible dans un paquet séparé. | |
377 | ||
378 | Parfois, les paquets incluent des copie du code source de leurs dépendances | |
379 | pour le confort de leurs utilisateurs. Cependant, en tant que distribution, | |
380 | nous voulons nous assurer que ces paquets utilisent bien les copient que | |
381 | nous avons déjà dans la distribution si elles existent. Cela améliore | |
382 | l'utilisation des ressources (la dépendance n'est construite et stockée | |
383 | qu'une seule fois) et permet à la distribution de faire des changements | |
384 | transversaux comme appliquer des correctifs de sécurité pour un paquet donné | |
385 | depuis un unique emplacement et qu'ils affectent tout le système, ce | |
386 | qu'empêchent les copies groupées. | |
387 | ||
388 | @item | |
389 | Regardez le profile rapporté par @command{guix size} (@pxref{Invoquer guix size}). Cela vous permettra de remarquer des références à d'autres paquets | |
390 | qui ont été retenus. Il peut aussi aider à déterminer s'il faut découper le | |
391 | paquet (@pxref{Des paquets avec plusieurs résultats}) et quelle dépendance | |
392 | facultative utiliser. | |
393 | ||
394 | @item | |
395 | Pour les changements important, vérifiez que les paquets qui en dépendent | |
396 | (s'ils existent) ne sont pas affectés par le changement ; @code{guix refresh | |
397 | --list-dependant @var{paquet}} vous aidera (@pxref{Invoquer guix refresh}). | |
398 | ||
399 | @c =========================================================================== | |
400 | @c | |
401 | @c This file was generated with po4a. Translate the source file. | |
402 | @c | |
403 | @c =========================================================================== | |
404 | @c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>. | |
405 | @cindex stratégie de branche | |
406 | @cindex stratégie de planification des reconstructions | |
407 | Suivant le nombre de paquets dépendants et donc le nombre de reconstruction | |
408 | induites, les commits vont vers des branches différentes, suivant ces | |
409 | principes : | |
410 | ||
411 | @table @asis | |
412 | @item 300 paquets dépendants ou moins | |
413 | branche @code{master} (changements non-disruptifs). | |
414 | ||
415 | @item entre 300 et 1 200 paquets dépendants | |
416 | branche @code{staging} (changemets non-disruptifs). Cette branche devrait | |
417 | être fusionnées dans @code{master} tous les 3 semaines. Les changements par | |
418 | thèmes (par exemple une mise à jour de la pile GNOME) peuvent aller dans une | |
419 | branche spécifique (disons, @code{gnome-updates}). | |
420 | ||
421 | @item plus de 1 200 paquets dépendants | |
422 | branche @code{core-updates} (peut inclure des changements majeurs et | |
423 | potentiellement disruptifs). Cette branche devrait être fusionnée dans | |
424 | @code{master} tous les 2,5 mois environ. | |
425 | @end table | |
426 | ||
427 | Toutes ces branches sont gérées par notre ferme de construction et | |
428 | fusionnées dans @code{master} une fois que tout a été construit | |
429 | correctement. Cela nous permet de corriger des problèmes avant qu'ils | |
430 | n'atteignent les utilisateurs et réduit la fenêtre pendant laquelle les | |
431 | binaires pré-construits ne sont pas disponibles. | |
432 | ||
433 | @item | |
434 | @cindex déterminisme, du processus de construction | |
435 | @cindex construction reproductibles, vérification | |
436 | Vérifiez si le processus de construction du paquet est déterministe. Cela | |
437 | signifie typiquement vérifier qu'une construction indépendante du paquet | |
438 | renvoie exactement le même résultat que vous avez obtenu, bit à bit. | |
439 | ||
440 | Une manière simple de le faire est de reconstruire le paquet plusieurs fois | |
441 | à la suite sur votre machine (@pxref{Invoquer guix build}) : | |
442 | ||
443 | @example | |
444 | guix build --rounds=2 mon-paquet | |
445 | @end example | |
446 | ||
447 | Cela est suffisant pour trouver une classe de non-déterminisme commune, | |
448 | comme l'horodatage ou des sorties générées aléatoirement dans le résultat de | |
449 | la construction. | |
450 | ||
451 | Une autre option consiste à utiliser @command{guix challenge} | |
452 | (@pxref{Invoquer guix challenge}). Vous pouvez lancer la commande une fois | |
453 | que les paquets ont été commités et construits par @code{hydra.gnu.org} pour | |
454 | vérifier s'il obtient le même résultat que vous. Mieux encore : trouvez une | |
455 | autre machine qui peut le construire et lancez @command{guix publish}. Puis | |
456 | la machine distante est sûrement différente de la vôtre, cela peut trouver | |
457 | des problèmes de non-déterminisme liés au matériel — par exemple utiliser | |
458 | une extension du jeu d'instruction — ou du noyau du système d'exploitation — | |
459 | par exemple se reposer sur @code{uname} ou les fichiers de @file{/proc}. | |
460 | ||
461 | @item | |
462 | Lorsque vous écrivez de la documentation, utilisez une formulation au genre | |
463 | neutre lorsque vous vous référez à des personnes, comme le | |
464 | @uref{https://fr.wikipedia.org/wiki/They_singulier, ``they''@comma{} | |
465 | ``their''@comma{} ``them'' singulier} (en anglais). | |
466 | ||
467 | @item | |
468 | Vérifiez que votre correctif contienne seulement un ensemble de changements | |
469 | liés. Grouper des changements non liés ensemble rend la revue plus difficile | |
470 | et plus lente. | |
471 | ||
472 | Ajouter plusieurs paquet ou une mise à jour d'un paquet avec des corrections | |
473 | dans ce paquet sont des exemples de changements sans rapport. | |
474 | ||
475 | @item | |
476 | Suivez nos règles de formatage de code, éventuellement en lançant le script | |
477 | @command{et/indent-code.el} pour le faire automatiquement (@pxref{Formatage | |
478 | du code}). | |
479 | ||
480 | @end enumerate | |
481 | ||
482 | Lorsque vous envoyez un correctif à la liste de diffusion, utilisez | |
483 | @samp{[PATCH] @dots{}} comme sujet. Vous pouvez utiliser votre client de | |
484 | courriel ou la commande @command{git send-email} (@pxref{Envoyer une série | |
485 | de correctifs}). Nous préférons recevoir des correctifs en texte brut, soit | |
486 | en ligne, soit en pièce-jointe MIME. Nous vous conseillons de faire | |
487 | attention si votre client de courriel change par exemple les retours à la | |
488 | ligne ou l'indentation, ce qui peut casser les correctifs. | |
489 | ||
490 | Lorsqu'un bogue est résolu, veuillez fermer le fil en envoyant un courriel à | |
491 | @email{@var{NNN}-done@@debbugs.gnu.org}. | |
492 | ||
493 | @unnumberedsubsec Envoyer une série de correctifs | |
494 | @anchor{Envoyer une série de correctifs} | |
495 | @cindex série de correctifs | |
496 | @cindex @code{git send-email} | |
497 | @cindex @code{git-send-email} | |
498 | ||
499 | @c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html | |
500 | Lorsque vous envoyez une série de correctifs (p.e. avec @code{git | |
501 | send-email}), envoyez d'abord une premier message à | |
502 | @email{guix-patches@@gnu.org} puis envoyez le reste des correctifs à | |
503 | @email{@var{NNN}@@debbugs.gnu.org} pour vous assurer qu'ils seront groupés | |
504 | ensemble. Voyez @uref{https://debbugs.gnu.org/Advanced.html, la | |
505 | documentation de Debbugs} pour plus d'informations. |