Comment soumettre un paquet correctif

Soumettre un paquet (patch) correctif, le faire vérifier et accepter par l'équipe de Mozilla nécessitent quelques étapes ; cet article vous explique comment faire.

Le processus de soumission est représenté par le diagramme ci-dessous, le tout vous étant expliqué en details à la suite.

Workflow of submitting a patch: Preparation | Module Ownership | Creating a patch
| Testing | Getting Reviews | Addressing Review Comments | Committing the Patch

Préparation

Tout changement dans le code provient d'un bogue déclaré sur bugzilla.mozilla.org ; sans bogue, le code ne sera pas examiné et sans évaluation, le code ne sera pas accepté. Afin d'éviter tout doublon, choisissez un bogue existant (en) à traiter et s'il n'y en a aucun, soumettez en un (en). La plupart des discussions à propos des futurs changements du code sont issues des bogues, alors assurez-vous que le rapport du bogue décrive exactement le problème à resoudre.

Vérifiez aussi que le rapport de bogue soit classé dans la bonne section (produit et composant). Pour plus d'information, vous pouvez poser des questions aux groupes de discussions ou sur le canal IRC des développeurs (en).

La personne travaillant sur un bogue se verra "assignée" à ce bogue sur bugzilla. Si quelqu'un d'autre y est déja désigné, envoyez un email a cette personne afin de vous coordonner ; sinon, laissez un message sur le bogue signalant que vous y travaillez et demandez que quelqu'un ayant les droits vous l'assigne.

Certaines équipes attendent que les nouveaux contributeurs effectuent leur premier patch avant de les assigner à un bogue, ce qui signifie qu'un bogue reste disponible pour les autres contributeurs, pour le cas où aucun patch ne soit jamais créé. En exprimant votre interet dans le commentaire d'un bogue, quelqu'un de l'equipe devrait vous guider sur le processus qu'elle utilise.

Le gestionnaire du module (en : ownership)

Tout le code est supervisé par un gestionnaire de module (en). Cette personne est responsable de l'évaluation et de l'approbation des changements. Avant d'écrire le code, determinez qui gére le module et verifiez avec lui que les changements proposés sont acceptables. L'équipe est peut être à la recherche d'une nouvelle interface utilisateur (évaluation de l'interface), de nouvelles fonctions (évaluation de l'API), ou des tests peuvent être en cours portant sur le changement proposé.

Si le gestionnaire du module ne vous semble pas clair, demandez aux groupes de discussion ou sur le canal IRC. Le journal de révision du fichier concerné peut aussi être utile. Par exemple, allez voir le journal de révision pourbrowser/base/content/browser.js, en cliquant sur le lien "Hg Log" au dessus de DXR ou en tapant hg log browser/base/content/browser.js. Le message de vérification correspondant contiendra quelque chose comme "r=nickname", identifiant les éventuels évaluateurs pour le code en question.

Création d'un paquet (en : patch)

Les changements du code source de Mozilla sont presentés sous forme de paquets. C'est essentiellement un engagement au contrôle de version.

Chaque paquet doit representer une seule correction complète, vous devez donc séparer les changements distincts en plusieurs paquets. Si votre changement se traduit par un grand paquet complexe, voyez s'il peut être décomposé en plusieurs petits correctifs plus faciles a comprendre (en). Cela faciliterait et fiabiliserait l'évaluation de vos changements, apprendre les évaluations rapides (en) .

Voir Comment générer un paquet (en) pour plus d'informations sur la création de paquets optimisés pour l'évaluation. Voir aussi notre liste de contrôle des évaluateurs (en) pour une liste des meilleures pratiques de présentation du correctif que les évaluateurs vérifient ou exigent.

Les tests

Tous les changements doivent être testés. Dans la plupart des cas, un test automatique (en) est requis pour tout changement dans le code.

En attendant d'avoir un test automatisé pour tout le code, nous avons un logiciel d'analyse statique sur notre JavaScript, pour contrôler les meilleures pratques et les erreurs communes. Voir ESLint (en) pour plus d'informations.

Assurez-vous que le changement ne cause pas de régressions en exécutant la suite de tests atomatique, en local, ou en utilisant le serveur de tests de Mozilla. Un gestionnaire de module ou un developpeur sur IRC peut être disponible pour soumettre ces travaux à la place des personnes n'ayant pas accès au serveur de tests.

Soumission du paquet

Assurez vous de la compatibilité de votre paquet avec les dernières versions de manière à éviter tout conflit.

En tant que contributeur, vous devez utiliser MozReview pour soumettre vos paquets. Voir le Guide d'utilisation de MozReview  (en) pour plus d'informations.

Si vous utilisez Mercurial, l'utilisation de l'extension bzexport  (en) est le mécanisme privilégié pour attacher des paquets sur Bugzilla. La façon la plus facile d'installer bzexport est d'exécuter mach mercurial-setup. Après ça, exécutez simplement hg bzexport -e pour télécharger un paquet dans Bugzilla sans avoir a quitter le terminal.

Si vous n'utilisez pas MozReview ou bzexport, liez le paquet au bug en utilisant l'option "Add an attachment link" dans bugzilla. Vérifiez la "patch box"  quand vous liez le paquet pour que les évaluateurs et les utilisateurs de bugzilla puissent le lire.

N'hésitez pas à poster des paquets partiels montrant les approches potentielles et demandez des retours sur ces derniers. Il est plus facile pour les autres de commenter et d'apporter des suggestions quand une question est illustrée par du code.

Obtention de l'évaluation

L'examen approfondi du code est un moyen mis en place par Mozilla dans le but d'obtenir un code de qualité. Tous les paquets doivent être vérifiés par le gestionnaire du module concerné ou l'un de ses pairs. Les paquets entrant dans plusieurs modules, changeant des API, ou comportant des modifications liées à la securité, feront l'objet d'une super-évaluaion(en) supplémentaire.

Pour plus d'informations à propos du processus d'évaluation, voyez la FAQ dédiée à l'évaluation du code (en). Si vos changements concernent l'interface graphique, allez voir "Les demandes de commentaires et les évaluations concernant l'interface graphique utilisateur de Firefox" (en).

request-review.pngPour demander une évaluation ou une super-évaluation, cliquez sur le lien "Details". Il y a sur le côté gauche, un menu déroulant avec plusieurs étiquettes. Trouvez l'étiquette "review" et changez l'option sur  "?", puis entrez l'adresse mail du gestionnaire du module ou de la personne qui examinera le patch. N'oubliez pas de soumettre des modifications !

Attention !: si l'évaluateur n'a pas repondu au bout d'une semaine environ :

  • Allez sur le canal #developers de l'IRC de Mozilla et demandez si quelqu'un a des informations sur les évaluations (en insérant le lien du bug en question sur le canal).
  • Dans un deuxième temps, envoyez un courriel directement à l'évaluateur, demandez-lui si/quand il aura le temps d'évaluer le correctif ou qui d'autre pourrait le faire.
  • En dernier ressort, demandez dans le groupe de discussion approprié sur news.mozilla.org.

Réponse aux commentaires de l'évaluation

Il est inhabituel qu'un correctif soit parfait dès la première fois. L'évaluateur marque "review-" et liste les problèmes rencontrés à corriger avant que le paquet puisse être accepté . Souvenez-vous que l'évaluation ne vise pas à vous décourager mais plutôt à encourager la meilleure résolution possible du bogue. Travaillez soigneusement les changements recommandés par l'évaluateur, joignez un nouveau correctif et demandez un nouvel examen.

Parfois, un évaluateur accordera une approbation conditionnelle en marquant "review +" mais en indiquant des modifications mineures qui doivent être apportées, telles que les corrections d'orthographe ou d'indentation. Toutes les recommandation doivent être suivies, mais une nouvelle évaluation ne sera pas nécessaire. Effectuez les changements, liez la version corrigée, et cochez la case correspondante pour rendre le patch original obsolète. S'il y a une confusion à ce stade, une nouvelle évaluation devra être effectuée.

Parfois après une évaluationi positive du correctif, mais avant sa publication, quelqu'un d'autre peut publier un changement qui entre en conflit avec le vôtre. Si la fusion est simple et non-invasive, publiez une version compatible, mais pour tout changement plus important, une évaluation supplémentaire sera nécessaire.

Si, à un moment donné, le processus d'évaluation s'arrête pendant plus de deux semaines, consultez la section  «Attention» ci-dessus.

Dans de nombreux projets open-source, les développeurs acceptent les correctifs inachevés, les finissent et les appliquent. Dans la philosophie de Mozilla, le vérificateur va seulement évaluer et commenter le paquet du contributeur. Si ce dernier refuse d'améliorer son correctif, le paquet restera tel quel jusqu'à ce que quelqu'un décide de s'en occuper.

Envoi du correctif

Un paquet peut être envoyé après avoir été proprement corrigé.

Compilez l'application avec le correctif, assurez-vous qu'elle s'exécute et passez la aux tests automatiques (et mentionnez que vous l'avez fait dans le bogue), et/ou envoyez au serveur de tests (en) (indiquez le aussi dans le bug). L'insertion d'un correctif non testé fait perdre du temps à la personne qui doit le faire et peut mettre le feu à l'arborescense. Faites gagner du temps et des efforts à tout le monde en réalisant toutes les vérifications nécessaires.

Assurez-vous que le patch est correctement formaté (en) afin de rendre son contrôle aussi facile que possible.

Ajoutez le mot-clé checkin-needed au bug (ou si Bugzilla ne vous autorise pas à ajouter ce mot-clé, demandez à quelqu'un de l'ajouter). Les membres de la communauté ayant les droits recherchent regulièrement des bugs avec le mot-clé checkin-needed et les intègrent dans un délai d'environ un jour. Si le correctif n'est pas vérifié dans un délai raisonnable, rendez-vous sur le canal #developers de irc.mozilla.org (en) et demandez à quelqu'un de le vérifier en votre nom. La plupart du temps, un lien vers une exécution test passée sera requis dans le but de vérifier que le patch ne causera pas de problèmes après son envoi.

Si vous publiez vous même, suivez les Règles de publication et de responsabilité.

Régressions

Il se pourrait que votre code provoque des régressions fonctionnelles ou une baisse de performance. il y a une politique rigoureuse vis-à-vis des baisses de performances en particulier, ce qui signifie que votre code peut être retiré et que vous allez devoir le retravailler pour le soumettre à nouveau. La régression signifie que les tests (que vous avez effectués avant l'envoi du correctif, n'est ce pas ?) n'étaient pas exhaustifs, alors vous allez devoir re-soumettre votre paquet ou faire un nouveau paquet pour corriger la régression, et réaliser les tests appropriés.

Après la création de quelques correctifs, envisagez d'avoir accès au code source de Mozilla (en).

Étiquettes et contributeurs liés au document

 Contributeurs à cette page : loella16, KurtC0ba1n
 Dernière mise à jour par : loella16,