MDN will be in maintenance mode on Wednesday September 20th, starting at 10 AM Pacific / 5 PM UTC, for about 1 hour.

How to submit a patch

Cette traduction est en cours.

Soumettre un patch, le faire verifier et accepter par l'équipe de Mozilla nécéssite quelques étapes; Cette article vous expliquera comment faire.

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

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 bug déclaré sur bugzilla.mozilla.org; sans bugs, le code ne sera pas examiné et sans examination, le code ne sera pas accepté. Afin d'éviter toute duplication, choisissez un bug existant (ANGL) a patché et si il n'y en a aucun, soumettez en un (ANGL). La pluparts des discussions à propos des futures changements du code sont issue des bugs, alors assurez-vous que le rapport du bug soit assez descriptif en vue de resoudre le problème rapidement.

Verifiez aussi que le rapport de bug soit classé dans la bonne section correspondante au logiciel sur lequel vous avez recontré ce bug. Pour plus d'information, vous pouvez poser des questions aux groupes de discussions ou bien sur le #chat IRC des développeurs (ANGL).

La personne travaillant sur un bug se verra "assigné" à ce bug sur bugzilla. Si quelqu'un d'autre y est déja assigné, envoyez un email a cette personne afin de vous arranger; sinon, laissez un message comme quoi vous travaillez sur ce bug et demandez que quelqu'un ayant les droits d'assignement aux bugs vous y assigne.

Quelques équipes attendent que les nouveaux contributeurs effectue leur premier patch avant de les assigner a un bug, ce qui signifie que un bug reste disponible pour les autres contributeurs au cas ou un patch n'est jamais créé. En exprimant votre interet pour un bug dans un commentaire, quelqu'un de l'equipe devrait vous guider sur la façon dont il s'y est pris pour resoudre ce bug.

Le gérant du module

Tout le code est supervisée par un gérant (ANGL). Cette personne est responsable de la revision et de l'acceptation des changements. Avant d'écrire le code, determinez qui gére le module et verifiez avec lui que les changements proposé ne posent pas de problèmes. Ils sont peut être à la recherche d'une nouvelle interface (revision de l'interface), d'une fonction (revision de l'API), ou de tests pour le changement proposé.

Si le gérant du module vous semble confus ou bien que vous n'avez pas compris, demandez aux groupes de discussion ou alors par chat IRC. Le journal de révision peut aussi être utile pour les fichiers pertinents. 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. L'enregistrement correspondant au message contiendra quelque chose comme "r=nickname", identifiant de potentiels revisions pour le code en question.

Créer un patch

Les changements du code source de Mozilla sont presenté sous forme de patch. Un patch est essentiellement un ajout au controle de version.

Chaque patchs devrais representer une seule correction complète, alors vous devriez séparer distinctement les changements en plusieurs patchs. Si votre changement se traduit par un grand patch complexe pouvant être séparer en plusieurs petites parties et facile a comprendre (ANGL). Cela rendrai les changements plus facile a réviser, apprendre les révisions rapide (ANGL).

Voir Comment générer un patch (ANGL). Pour plus d'information sur la création de patchs optimisé pour la révision, rendez-vous sur La liste des choses a faire pour une révision (ANGL) pour une liste des meilleurs pratiques pour patcher du contenus que les personne revisant votre patch recherchent ou nécessitent

Le test

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

En attendant d'avoir un test automatisé pour tout les codes, nous avons un logiciel d'analyse statique sur notre JavaScript pour les meilleurs pratques et les erreurs communes. Allez voir ESLint (ANGL) pour plus d'informations.

Assurez-vous que le changement ne cause pas de regressions en executant le test atomatique, en local, ou en utilisant le serveur d'essais de Mozilla. Un gérant de module ou un developpeur sur IRC peut être disposé à donner du travail pour les personnes n'ayant pas accès au serveur d'essais.

Soumettre le patch

Assurez vous de la compatibilité de votre patch avec les dernieres versions en de manière a éviter tout conflits.

En tant que contributeur, vous devriez utiliser MozReview for afin de soumettre des patchs. Allez voir le Guide d'utilisation de MozReview  (ANGL) pour plus d'informations.

Si vous utilisez Mercurial, L'installation de l'extension bzexport  (ANGL) vous rendra la tache plus facile pour poster des patchs sur Bugzilla. La façon la plus facile d'installer bzexport est de d'executer mach mercurial-setup. Après ça, executez simplement hg bzexport -e pour uploader un patch a Bugzilla sans avoir a quitter le terminal.

Si vous n'utilisez pas MozReview ou bzexport, liez le fichier patch au bug en utilisant le "Add an attachment link" dans bugzilla. Verifiez la "patch box"  quand vous liez le patch pour que les personnes s'occupant des revisions et les utilisateurs de bugzilla puisse le lire.

N'hesitez pas a poster des patchs partiels demontrants comment potentielement corriger un bug et demander des retours sur ces derniers. Il est facile pour les autres de commenter et de proposer des suggestions quand une question est illustré par un code.

Faire reviser son patch

L'examen approfondis du code est un moyen mis en place par Mozilla dans le but d'obtenir un code de qualité. Tout les patchs se doivent d'être verifier par le gérant du module concerné par le code ou bien par un des personnes designé par ce dernier. Les patchs entrant en ligne de compte de plusieurs modules, les changements d'APIs, ou bien les changement relatif a la securité feront l'objet d'une super-revision(ANGL).

Pour plus d'information a propos du processus de revision, allez voir la FAQ dedié (ANGL) à la revision du code. Si vos changements concerne l'interface graphique, allez voir "Les requetes de retours et les revisions graphiques concernant l'interface de Firefox" (ANGL).

request-review.pngPour demander une revision ou une super-revision, cliquez sur le lien "Details" pour le lier a bugzilla. Il y a sur le coté gauche, un menu deroulant avec plusieurs étiquettes. Trouvez l'étiquette "review" et changez l'option sur  "?", puis entrez l'adresse mail du gérant du module ou la personne qu'il a designé pour reviser le patch.

Attention !: si la personne devant reviser votre code ne repond pas dans la semaine:

  • Aller sur #developers sur les serveurs IRC de Mozilla et demandez si quelqu'un sait pourquoi une revision pourrait avoir du retard (en mettant le lien du bug dans la question bien sur).
  • Dans un deuxieme temps, envoyez un mail ta la personne se chargeant de votre code, demandez si/quand elle aura le temps de reviser le patch ou de delaisser la revision a quelqu'un d'autre pouvant la faire.
  • En dernier ressort, demandez dans le groupe de discussion aproprié sur news.mozilla.org.

Ameliorer et perfectionner son patch

Il est peu voir pas commun de voir un patch parfait dès la premiere fois. La personne ayant verifier votre patch pourrai marquer "review-" et lister les problèmes rencontrer à corriger avant que le patch ne soit accepté . Souvenez vous que les patchs qui vous sont/seront retourné avec une liste de correctif a effectuer ne sont pas a prendre comme un signe de decouragement mais plutot d'encouragement a fournir la meilleur soution possible de manière à resoudre le bug. Essayez de suivre au mieux les recommandations de vos verficateurs, liez le nouveau patch et redemandez une revision.

Parfois, il arrivera qu'un verificateur vous retourne votre patch avec une liste de choses en plus a integrer en marquant "review+" ces changements a apporter a votre patch seront mineurs et facultative, sauf l'indentation ou l'orthographe. Toute les recommandation devrai être appliqué, mais une re-revision de sera pas neccessaire. Effectuez les changements, liez la version revisé, et cochez la case sur la page permettant de rendre le patch original obsolète. Si il y a un probleme de revision, ou un malentendu, une autre revision devra être effectué.

Parfois après une revision de patch, mais avant son ajout, quelqu'un d'autre peut publier un autre patch qui entrera en conflit avec le votre. Si la fusion est simple et non-invasive, postez une version du patch compatible, mais pour tout changement non trivial, une revision supplementaire sera necessaire.

Si pour une raison dont vous ignorez l'existence, votre patch met plus de 2 semaine a se faire revisé, allez voir la section "Attention !" ci-dessus.

Dans beaucoup de projets open-source, les developeurs vont accepter les patchs inachevé, les finir et les appliqué. Dans la philosophie de Mozilla, le verificateur va seulement reviser et commenter les patchs que les contributeurs lui donneront. Si le contributeur refuse de revoir son patch, le patch restera tel quel jusqu'a ce que quelqu'un decide de s'en occuper.

Envoyer le patch

Un patch peut etre envoyer après être proprement revisé.

Compilez l'application avec le patch de facon à regarder si la compilation se passe sans problemes et passer le test automatique, ensuite/ou envoyez au serveur d'essai (ANGL)(en precisant cela dans le rapport de bug). Soumettre un patch non testé fais perdre du temps à la personne responsable de l'ajout du patch. Faites gagner du temps et des efforts à tout le monde: completez toute les verification nécessaire.

Assurez-vous que le patch est proprement mis au bon format (ANGL) en vue de faciliter la tache aux personnes verifiant votre patch.

Ajoutez le mot clé checkin-needed au bug (ou si Bugzilla ne vous autorise pas a ajouter ce mot clé, demandez a quelqu'un de le faire a votre place). Les membres de la communauté avec un acces au code source (en mode écriture) recherchent regulièrement des bugs avec le mot clé checkin-needed et verifieront votre patch dans les jours qui suivent. Si le patch n'est pas verifié au bout d'un certains laps de temps, rendez vous sur le canal #developers de irc.mozilla.org (ANGL) et demandez à quelqu'un de le verifier a votre nom. La plupart du temps, un lien vers un passage "essayer d'executer" sera requis dans le but de verifier que le patch ne causera pas de problemes après avoir été envoyer.

Si vous publiez vous même, suivez les Regles de publication et de responsabilité.

Regressions

Ce peut être votre faute si le code cause des problemes technique tel qu'une baisse de performance ou une fonctionnalité en moins, il y a une politique très strict vis a vis des baisses de performances, ce qui signifie que votre code a beau être sans erreur et reussi, vous allez devoir le retravailler pour le re-soumettre. La regression signifie que les tests (que vous avez effectué avant de faire verifier votre programme, n'est ce pas ?) ne sont pas assez compréhensible et clair, alors vous allez devoir re-soumettre votre patch ou encore patcher la regression, le tout devant être effectué avec les tests appproprié.

Après la creation de quelques patchs, envisagez d'avoir un accès en écriture aux codes source de Mozilla (ANGL).

Étiquettes et contributeurs liés au document

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