Suivant: Suivi des bogues et des correctifs, Précédent: Style de code, Monter: Contribuer [Table des matières][Index]
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
(voir Submitting patches to a project dans Git User Manual). Si vous
voulez contribuer, nous vous encourageons à prendre un moment pour changer
quelques options du dépôt Git pour améliorer la lisibilité des correctifs
avant de commencer (voir Configurer Git). Si vous avez bien expérimenté
la contribution à Guix, vous pouvez aussi regarder la section sur les accès
en commit (voir Accès en commit).
Cette liste de diffusion est gérée par une instance Debbugs, qui nous permet
de suivre les soumissions. Chaque message envoyé à cette liste se voit
attribuer un nouveau numéro de suivi ; les gens peuvent ensuite répondre à
cette soumission en envoyant un courriel à
NUMÉRO_PROBLÈME@debbugs.gnu.org, où NUMÉRO_PROBLÈME est
le numéro de suivi (voir Envoyer une série de correctifs).
Veuillez écrire les messages de commit dans le format ChangeLog (voir Change Logs dans 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 :
gpg --verify.
guix lint paquet, où paquet est le nom du nouveau
paquet ou du paquet modifié, et corrigez les erreurs qu’il rapporte
(voir Invoquer guix lint).
guix style paquet pour formater la nouvelle définition
du paquet en suivant les conventions du projet (voir Invoquer guix style).
guix build paquet.
qemu-binfmt-service-type pour les émuler. Pour cela, ajoutez le
module de service virtualization et le service suivant à la liste des
services dans votre configuration de système d’exploitation :
(service qemu-binfmt-service-type
(qemu-binfmt-configuration
(platforms (lookup-qemu-platforms "arm" "aarch64"))))
Puis reconfigurez votre système.
Vous pourrez ensuite construire les paquets pour différentes plate-formes en
spécifiant l’option --system. Par exemple pour construire le paquet
« hello » pour les architectures armhf ou aarch64, vous devrez lancer les
commandes suivantes, respectivement :
guix build --system=armhf-linux --rounds=2 hello guix build --system=aarch64-linux --rounds=2 hello
Parfois, les paquets incluent des copie du code source de leurs dépendances pour le confort des utilisateur·rices. Cependant, en tant que distribution, nous voulons nous assurer que ces paquets utilisent bien les copient que nous avons déjà dans la distribution si elles existent. Cela améliore l’utilisation des ressources (la dépendance n’est construite et stockée qu’une seule fois) et permet à la distribution de faire des changements transversaux comme appliquer des correctifs de sécurité pour un paquet donné depuis un unique emplacement et qu’ils affectent tout le système, ce qu’empêchent les copies groupées.
guix size (voir Invoquer guix size). Cela vous permettra de remarquer des références à d’autres paquets
qui ont été retenus sans que vous vous y attendiez. Il peut aussi aider à
déterminer s’il faut découper le paquet (voir Des paquets avec plusieurs résultats) et quelles dépendances facultatives utiliser. En particulier,
évitez d’ajouter texlive en dépendance : à cause de sa taille
extrême, utilisez texlive-tiny ou texlive-union à la place.
guix refresh
--list-dependant paquet vous aidera (voir 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 :
branche master (changements non-disruptifs).
branche staging (changements non-disruptifs). Cette branche devrait
être fusionnées dans master toutes les 6 semaines. Les changements
par thèmes (par exemple une mise à jour de la pile GNOME) peuvent aller dans
une branche spécifique (disons, gnome-updates). Il n’est pas
forcément possible de construire ni utiliser cette branche jusque tard dans
le processus de développement.
la branche core-updates (peut inclure des changements majeurs et
potentiellement disruptifs). Cette branche devrait être fusionnée dans
master tous les 6 mois environ. Il n’est pas forcément possible de
construire ni utiliser cette branche jusque tard dans le processus de
développement.
Toutes ces branches sont gérées
par notre ferme de construction 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 utilisateur·rices et réduit la
fenêtre pendant laquelle les binaires pré-construits ne sont pas
disponibles.
Lorsqu’on décide de commencer à construire la branche staging ou
core-updates, on les fork et on les renomme avec le suffixe
-frozen, et à partir de ce moment, seuls les corrections de bogues
sont poussées sur les branches gelées. Les branches core-updates et
staging restent ouvertes et acceptent des correctifs pour le prochain
cycle. Demandez sur la liste de diffusion ou sur IRC si vous ne savez pas où
envoyer un correctif.
Une manière simple de le faire est de reconstruire le paquet plusieurs fois
à la suite sur votre machine (voir 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
(voir Invoquer guix challenge). Vous pouvez lancer la commande une fois
que les paquets ont été committés et construits par
ci.guix.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. Puisque la machine distante
est sûrement différente de la vôtre, cela peut trouver des problèmes de
non-déterminisme liés au matériel — par exemple utiliser une extension du
jeu d’instruction — ou du noyau du système d’exploitation — par exemple se
reposer sur uname ou les fichiers de /proc.
Ajouter plusieurs paquet ou une mise à jour d’un paquet avec des corrections dans ce paquet sont des exemples de changements sans rapport.
guix style pour le faire automatiquement (voir Formatage du code).
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.
guix pull avec :
guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master
Lorsque vous envoyez un correctif à la liste de diffusion, utilisez
‘[PATCH] …’ comme objet. Si votre correctif doit être appliqué à
une autre branche que master, comme core-updates, spécifiez-le
dans l’objet comme dans ‘[PATCH core-updates] …’.
Vous pouvez utiliser votre client de messagerie ou la commande git
send-email (voir Envoyer une série de correctifs). Nous préférons recevoir les
correctifs dans des messages en texte clair, soit en ligne, soit sous forme
de pièces jointes MIME. Il vous est conseillé de faire attention si votre
client de messagerie modifie quoi que ce soit, comme des sauts de ligne ou
des indentations, qui pourraient potentiellement casser les correctifs.
Attendez-vous à un délai entre le moment où vous envoyez votre tout premier correctif à guix-patches@gnu.org et le moment où le message sera reçu. Vous devez attendre de recevoir un message de confirmation avec le numéro de suivi assigné à votre correctif. Les confirmations suivantes ne seront pas retardées.
Lorsqu’un bogue est résolu, veuillez fermer le fil en envoyant un courriel à NUMÉRO_PROBLÈME-done@debbugs.gnu.org.
Suivant: Suivi des bogues et des correctifs, Précédent: Style de code, Monter: Contribuer [Table des matières][Index]