Suivant: , Précédent: , Monter: Contribuer   [Table des matières][Index]


14.6 Envoyer des correctifs

Development is done using the Git distributed version control system. Thus, access to the repository is not strictly necessary. We welcome contributions in the form of patches as produced by git format-patch sent to the guix-patches@gnu.org mailing list. Seasoned Guix developers may also want to look at the section on commit access (voir Commit Access).

This mailing list is backed by a Debbugs instance, which allows us to keep track of submissions (voir Tracking Bugs and Patches). Each message sent to that mailing list gets a new tracking number assigned; people can then follow up on the submission by sending email to NNN@debbugs.gnu.org, where NNN is the tracking number (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 :

  1. Si les auteurs ou autrices du paquet logiciel fournissent une signature cryptographique pour l’archive, faites un effort pour vérifier l’authenticité de l’archive. Pour un fichier de signature GPG détaché, cela se fait avec la commande gpg --verify.
  2. Prenez un peu de temps pour fournir un synopsis et une description adéquats pour le paquet. Voir 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 (voir Invoquer guix lint).
  4. Assurez-vous que le paquet se construise sur votre plate-forme avec guix build paquet.
  5. Nous vous recommandons aussi d’essayer de construire le paquet sur les autres plate-formes prises en charge. Comme vous n’avez pas forcément accès aux plate-formes matérielles, nous vous recommandons d’utiliser le qemu-binfmt-service-type pour les émuler. Pour cela, ajoutez 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" "mips64el"))
       (guix-support? #t)))
    

    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, aarch64 ou mips64, vous devrez lancer les commandes suivantes, respectivement :

    guix build --system=armhf-linux --rounds=2 hello
    guix build --system=aarch64-linux --rounds=2 hello
    guix build --system=mips64el-linux --rounds=2 hello
    
  6. Assurez-vous que le paquet n’utilise pas de copie groupée d’un logiciel déjà disponible dans un paquet séparé.

    Parfois, les paquets incluent des copie du code source de leurs dépendances pour le confort des utilisateur·rice·s. 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.

  7. Regardez le profil rapporté par 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.
  8. 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 (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 :

    300 paquets dépendants ou moins

    branche master (changements non-disruptifs).

    entre 300 et 1 200 paquets dépendants

    branche staging (changements 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.

    All these branches are tracked by our build farm and merged into master once everything has been successfully built. This allows us to fix issues before they hit users, and to reduce the window during which pre-built binaries are not available.

    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.

  9. 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 (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.

  10. 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 (en anglais).
  11. 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.

  12. Suivez nos règles de formatage de code, éventuellement en lançant le script et/indent-code.el pour le faire automatiquement (voir Formatage du code).
  13. Si possible, utilisez des miroirs dans l’URL des sources (voir 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.
  14. Check if Guix builds (voir Construire depuis Git) and address the warnings, especially those about use of undefined symbols.
  15. Make sure your changes do not break Guix and simulate a guix pull with:
    guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master
    

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 (voir 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

When sending a patch series (e.g., using git send-email), please first send one message to guix-patches@gnu.org, and then send subsequent patches to NNN@debbugs.gnu.org to make sure they are kept together. See the Debbugs documentation for more information. You can install git send-email with guix install git:send-email.


Suivant: , Précédent: , Monter: Contribuer   [Table des matières][Index]