22.8.1 Candidater pour avoir accès en commit

Lorsque vous l’estimez nécessaire, pensez à candidater à l’accès en commit en suivant les étapes suivantes :

1. Trouvez trois personnes ayant les accès en commit et qui soutiendront votre candidature. Vous pouvez trouver la liste de ces personnes sur https://savannah.gnu.org/project/memberlist.php?group=guix. Chacune d’entre elles devra envoyer une déclaration à guix-maintainers@gnu.org (un alias privé pour le collectif des mainteneur·ses), signé de leur clef OpenPGP.

   Les commiteurs devront avoir eu des interactions avec vous en tant que contributeur et pouvoir juger si vous êtes suffisament familier avec les pratiques du projet. Ce n’est pas un jugement sur la valeur de votre travail, donc vous devriez plutôt interpréter un refus comme un « essayons un peu plus tard ».

2. Envoyez un message à guix-maintainers@gnu.org déclarant votre intention, listant les trois commiteur·ses qui supportent votre candidature, signez-le avec la clef OpenPGP que vous utiliserez pour signer vos commits et donnez son empreinte (voir plus bas). Voir https://emailselfdefense.fsf.org/fr/, pour une introduction à la cryptopgraphie à clef publique avec GnuPG.

   Configurer GnuPG de manière à ce qu’il n’utilise jamais l’algorithme de hachage SHA1 pour les signatures numériques, dont on sait qu’il est dangereux depuis 2019, par exemple en ajoutant la ligne suivante à ~/.gnupg/gpg.conf (voir GPG Esoteric Options dans The GNU Privacy Guard Manual) :

   digest-algo sha512
   

3. Les mainteneur·ses ont le dernier mot sur la décision de vous donner accès et suivent généralement l’avis de vos référents.
4. Si vous obtenez l’accès, envoyez un message à guix-devel@gnu.org pour le faire savoir, en signant de nouveau avec le clef OpenPGP que vous utiliserez pour signer les commits (faites-le avant votre premier commit). De cette manière, tout le monde peut s’en rendre compte et s’assurer que c’est bien vous qui contrôlez cette clef OpenPGP.

   Important : Avant d’envoyer pour la première fois, les mainteneur·ses doivent :

   1. ajoutez votre clé OpenPGP à la branche keyring ;
   2. ajoutez votre empreinte OpenPGP au fichier .guix-authorizations de la (des) branche(s) sur laquelle (lesquelles) vous vous engagez.

5. Assurez-vous de lire le reste de cette section et… profitez !

Remarque : Les mainteneur·ses se réjouissent de donnéer l’accès en commit aux personnes qui ont contribué depuis un certain temps et ont un historique — ne soyez pas timide et ne sous-estimez pas votre travail !

Cependant, remarquez que le projet travail sur un système de revu de correctifs et de fusion plus automatisé, qui, en conséquence, pourra nous faire réduire le nombre de personne ayant accès en commit au dépôt principal. Restez à l’écoute !

Tous les commits poussés sur le dépôt central sur Savannah doivent être signés avec une clef OpenPGP et la clef publique doit être chargée sur votre compte utilisateur dans Savannah et les serveurs de clef publique, comme keys.opengpg.org. Pour configurer Git pour signer automatiquement vos commits, lancez :

git config commit.gpgsign true

# Remplacez l'empreinte par celle de votre clé PGP publique
git config user.signingkey CABBA6EA1DC0FF33

Pour vérifier que les commits sont signés avec une clé correcte, utilisez :

make authenticate

Vous pouvez éviter de pousser accidentellement des commits non signés ou signés avec une mauvaise clé vers Savannah et utilisant le crochet Git de pré-envoi situé dans etc/git/pre-push :

cp etc/git/pre-push .git/hooks/pre-push

II appelle aussi make-check-channel-news pour s’assurer que le fichier news.scm est correct.

22.8.2 Politique de commit

Si vous avez accès en commit, assurez-vous de respecter la politique ci-dessous (les discussions à propos de cette politique peuvent avoir lieu sur guix-devel@gnu.org).

Les correctifs non triviaux doivent toujours être postés sur guix-patches@gnu.org (les correctifs triviaux consistent en des correctifs de coquilles, etc). Cette liste de diffusion rempli la base de données de correctifs (voir Suivi des bogues et des correctifs).

Pour les correctifs qui ne font qu’ajouter un nouveau paquet, et un paquet simple, commiter directement est accepté si vous êtes en confiance (ce qui signifie que vous avez réussi à le construire dans un environnement chroot et avez fait un audit suffisant des copyrights et de la licence). Pareil pour les mises à jour de paquets, sauf pour les mises à jour qui occasionnent beaucoup de reconstruction (par exemple mettre à jour GnuTLS ou GLib). Nous avons une liste de diffusion pour les notifications de commit (guix-commits@gnu.org), pour que les gens puissent s’en rendre compte. Avant de pousser vos changements, assurez-vous d’avoir lancé git pull --rebase.

Lorsque vous poussez un commit pour le compte de quelqu’un d’autre, ajoutez une ligne Signed-off-by à la fin du message de commit — p. ex. avec git am --signoff. Cela amélior le suivi que qui fait quoi.

Quand vous ajoutez de nouvelles entrées au canal (voir Writing Channel News), assurez-vous qu’elles sont bien formées en exécutant la commande suivante juste avant d’envoyer :

make check-channel-news

Pour tout autre chose, envoyez un correctif à guix-patches@gnu.org et laissez un peu de temps pour la revue, sans rien commiter (voir Envoyer des correctifs). Si vous ne recevez pas de réponse dans les deux semaines et que vous avez confiance, vous pouvez commiter.

La dernière partie est sujète à ajustement, pour permettre à certains de commiter directement des changements non controversés sur des parties qui leurs sont familières.

22.8.3 Régler les problèmes

La revue par les pairs (voir Envoyer des correctifs) et les outils comme guix lint (voir Invoquer guix lint) et la suite de tests (voir Lancer la suite de tests) devraient trouver les problèmes avant qu’ils ne soient poussés. Pourtant, il arrive parfois que des commits qui « cassent » une fonctionnalité passent à travers les mailles du filet. Lorsque cela arrive, il y a deux priorités : minimiser l’impact et comprendre ce qui s’est passé, pour réduire les chances qu’un incident similaire se produise à nouveau. Les personnes impliquées ont la plus grande part de responsabilité dans ces deux tâches, mais comme pour tout le reste, c’est aussi un travail commun.

Certains problèmes peuvent directement affecter les utilisateurs et utilisatrices — par exemple si guix pull échoue ou qu’une fonctionnalité importante est cassée parce que des paquets importants sont cassés (à la construction ou à l’exécution), ou parce qu’ils introduisent des problèmes de sécurités connus.

Les personnes impliquées, auteurs, relecteurs et ayant poussé ces commits devraient avant tout réduire leur impact rapidement en poussant un nouveau commit qui le corrige (si c’est possible) ou en inversant les commits pour laisser du temps avant de trouver un correctif satisfaisant, et en communiquant le problème aux autres développeurs.

Si ces personnes ne peuvent pas s’occuper du problème à temps, les autres commiteurs peuvent inverser les commits, en expliquant le problème dans le message de commit et sur la liste de diffusion, dans le but de donner du temps au commiteur, aux relecteurs et aux auteurs de proposer une solution.

Une fois que le problème a été réglé, il est de la responsabilité des personnes impliquées de s’assurer que la situation a été comprise. Si vous travaillez à comprendre ce qui est arrivé, efforcez-vous de récolter des informations plutôt que de désigner des coupables. Demandez aux gens impliqués de décrire ce qui est arrivé, ne leur demandez pas d’expliquer la situation – ce qui les mettrait implicitement dans une position de responsabilité et n’est d’aucune aide. La responsabilité vient une fois atteint un consensus sur le problème, qui permet d’apprendre de ce qui s’est passé et d’améliorer les processus afin qu’il soit moins à risque de se reproduire.

22.8.4 Révocation des droits en commit

Pour réduire la probabilité de faire une erreur, celles et ceux qui peuvent commiter seront retiré·e·s du projet Guix sur Savannah et leur clé supprimée de .guix-authorizations après 12 mois d’inactivité ; ils et elles pourront retrouver leur accès en envoyant un courriel aux mainteneur·ses, sans avoir à passer par le processus de cooptation.

Les mainteneur·ses⁴⁶ peuvent aussi révoquer les droits en commit de quelqu’un, en dernier recours, si la coopération avec le reste de la communauté a créé trop de friction – même en restant dans le cadre du code de conduite (voir Contribuer) du projet. Ils ne le feraient qu’après une discussion publique ou privée avec la personne concernée et un avertissement clair. Voici des exemples de comportements qui gênent la coopération et pourraient mener à une telle décision :

• enfreindre de manière répétée la politique de commit indiquée ci-dessus ;
• échouer de manière répétée à prendre en compte les critiques de la communauté ;
• briser la confiance suite à une série d’incidents graves.

Quand les mainteneurs recourent à une telle décision, ils en informent les développeurs sur guix-devel@gnu.org ; des questions peuvent être envoyées à guix-maintainers@gnu.org. Suivant la situation, les contributions de la personne peuvent rester bienvenues.

22.8.5 Aider

Une dernière chose : le projet continue à avancer non seulement parce que les commiteurs poussent leurs propres changements, mais aussi parce qu’ils offrent de leur temps pour revoir et pousser les changements des autres personnes. En tant que commiteur, vous pouvez utiliser votre expertise et vos droits en commit pour aider d’autres contributeaurs aussi !