initial commit

1 files changed, 108 insertions, 0 deletions

diff --git a/files/fr/mozilla/developer_guide/how_to_submit_a_patch/index.html b/files/fr/mozilla/developer_guide/how_to_submit_a_patch/index.html
new file mode 100644
index 0000000000..9586c69a11
--- /dev/null
+++ b/files/fr/mozilla/developer_guide/how_to_submit_a_patch/index.html
@@ -0,0 +1,108 @@
+---
+title: Comment soumettre un paquet correctif
+slug: Mozilla/Developer_guide/How_to_Submit_a_Patch
+translation_of: Mozilla/Developer_guide/How_to_Submit_a_Patch
+---
+<div class="summary">
+<p><span class="seoSummary">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.</span></p>
+</div>
+
+<p>Le processus de soumission est représenté par le diagramme ci-dessous, le tout vous étant expliqué en details à la suite.</p>
+
+<p style="text-align: center;"><img alt="Workflow of submitting a patch: Preparation | Module Ownership | Creating a patch
+| Testing | Getting Reviews | Addressing Review Comments | Committing the Patch" class="default internal" src="/@api/deki/files/3599/=submitting-patch-workflow.png" style="height: 348px; width: 267px;"></p>
+
+<h2 id="Préparation">Préparation</h2>
+
+<p>Tout changement dans le code provient d'un bogue déclaré sur <a class="link-https" href="https://bugzilla.mozilla.org/" title="https://bugzilla.mozilla.org/">bugzilla.mozilla.org</a> ; sans bogue, le code ne sera pas examiné et sans évaluation, le code ne sera pas accepté. Afin d'éviter tout doublon, <a class="link-https" href="https://bugzilla.mozilla.org/query.cgi?format=specific">choisissez un bogue existant</a> (en) à traiter et s'il n'y en a aucun, <a href="https://bugzilla.mozilla.org/enter_bug.cgi">soumettez en un (en)</a>. 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.</p>
+
+<p>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 <a href="irc://irc.mozilla.org/developers">canal IRC des développeurs (en).</a></p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<h2 id="Le_gestionnaire_du_module_(en_ownership)">Le gestionnaire du module (en : ownership)</h2>
+
+<p>Tout le code est supervisé par un <a class="internal" href="https://www.mozilla.org/en-US/about/governance/policies/module-ownership/" title="/en-US/docs/Mozilla Modules and Module Ownership">gestionnaire de module</a> (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é.</p>
+
+<p>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 pour{{ Source("browser/base/content/browser.js") }}, en cliquant sur le lien "Hg Log" au dessus de <a href="http://dxr.mozilla.org/mozilla/source/">DXR</a> ou en tapant <code>hg log browser/base/content/browser.js</code>. Le message de vérification correspondant contiendra quelque chose comme "r=nickname", identifiant les éventuels évaluateurs pour le code en question.</p>
+
+<h2 id="Création_d'un_paquet_(en_patch)">Création d'un paquet (en : patch)</h2>
+
+<p>Les changements du code source de Mozilla sont presentés sous forme de paquets. C'est essentiellement un engagement au contrôle de version.</p>
+
+<p>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 <a href="https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/#many-small-commits">petits correctifs plus faciles a comprendre</a> (en). Cela faciliterait et fiabiliserait l'évaluation de vos changements, <a class="external" href="http://groups.google.com/group/mozilla.dev.planning/msg/2f99460f57f776ef?hl=en" title="http://groups.google.com/group/mozilla.dev.planning/msg/2f99460f57f776ef?hl=en">apprendre les évaluations rapides (en)</a> .</p>
+
+<div class="note">
+<p>Voir <a href="/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F" title="/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F">Comment générer un paquet (en) </a>pour plus d'informations sur la création de paquets optimisés pour l'évaluation. Voir aussi notre <a href="/en-US/docs/Developer_Guide/Reviewer_Checklist">liste de contrôle des évaluateurs</a> (en) pour une liste des meilleures pratiques de présentation du correctif que les évaluateurs vérifient ou exigent.</p>
+</div>
+
+<h2 id="Les_tests">Les tests</h2>
+
+<p>Tous les changements doivent être testés. Dans la plupart des cas, un <a class="internal" href="/en-US/docs/Mozilla_automated_testing" title="/en-US/docs/Mozilla automated testing">test automatique</a> (en) est requis pour tout changement dans le code.</p>
+
+<p>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 <a href="/en-US/docs/ESLint">ESLint (en)</a> pour plus d'informations.</p>
+
+<p>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 <a class="link-https" href="https://wiki.mozilla.org/Build:TryServer" title="https://wiki.mozilla.org/Build:TryServer">serveur de tests de Mozilla</a>. 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.</p>
+
+<h2 id="Soumission_du_paquet">Soumission du paquet</h2>
+
+<div class="note">
+<p>Assurez vous de la compatibilité de votre paquet avec les dernières versions de manière à éviter tout conflit.</p>
+</div>
+
+<pre>En tant que contributeur, vous devez utiliser Phabricator pour soumettre vos paquets. Voir le <a href="https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html">Guide d'utilisation de Phabricator</a>  (en) pour plus d'informations.</pre>
+
+<p>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.</p>
+
+<h2 id="Getting_the_patch_reviewed" name="Getting_the_patch_reviewed">Obtention de l'évaluation</h2>
+
+<p>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 <a class="external" href="http://www.mozilla.org/hacking/reviewers.html">super-évaluaion</a>(en) supplémentaire.</p>
+
+<p>Pour plus d'informations à propos du processus d'évaluation, voyez la <a class="internal" href="/en-US/docs/Code_Review_FAQ" title="/en-US/docs/Code Review FAQ">FAQ dédiée à l'évaluation du code</a> (en). Si vos changements concernent l'interface graphique, allez voir "<a href="/en-US/docs/Developer_Guide/Requesting_feedback_and_ui-review_for_desktop_Firefox_front-end_changes" title="Requesting feedback and ui-review for desktop Firefox front-end changes">Les demandes de commentaires et les évaluations concernant l'interface graphique utilisateur de Firefox</a>" (en).</p>
+
+<p>Pour demander une évaluation, vous devrez fournir un ou pusieurs noms d'utilisateur: soit lors de la soumission du paquet, soit dans l'interface graphique.</p>
+
+<p>Voir la documentation <a href="https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html">Mozilla Phabricator</a> (en) pour plus de détails.</p>
+
+<p><em>Attention !:</em> si l'évaluateur n'a pas repondu au bout d'une semaine environ :</p>
+
+<ul>
+ <li>Allez sur le canal <a class="link-irc" href="irc://irc.mozilla.org/developers">#developers</a> 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).</li>
+ <li>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.</li>
+ <li>En dernier ressort, demandez dans le groupe de discussion approprié sur <code>news.mozilla.org</code>.</li>
+</ul>
+
+<h2 id="Réponse_aux_commentaires_de_l'évaluation">Réponse aux commentaires de l'évaluation</h2>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>Si, à un moment donné, le processus d'évaluation s'arrête pendant plus de deux semaines, consultez la section  «Attention» ci-dessus.</p>
+
+<p>Dans de nombreux projets open-source, les développeurs acceptent les correctifs inachevés, les finissent et les appliquent. Dans la philosophie de Mozilla, <strong>le vérificateur va seulement évaluer et commenter le paquet du contributeur</strong>. 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.</p>
+
+<h2 id="Getting_the_patch_checked_into_the_tree" name="Getting_the_patch_checked_into_the_tree">Envoi du correctif</h2>
+
+<p>Un paquet peut être envoyé après avoir été proprement corrigé.</p>
+
+<div class="note">
+<p>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 <a class="link-https" href="https://wiki.mozilla.org/Build:TryServerAsBranch" title="https://wiki.mozilla.org/Build:TryServerAsBranch">serveur de tests</a> (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.</p>
+
+<p>Assurez-vous que le patch est <a href="/en-US/docs/Mercurial/Using_Mercurial#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F" title="/en-US/docs/Creating_a_patch_that_can_be_checked_in">correctement formaté</a> (en) afin de rendre son contrôle aussi facile que possible.</p>
+</div>
+
+<p>Ajoutez le mot-clé <a class="link-https" href="https://bugzilla.mozilla.org/describekeywords.cgi#checkin-needed"><code>checkin-needed</code></a> 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é <a class="link-https" href="https://bugzilla.mozilla.org/describekeywords.cgi#checkin-needed"><code>checkin-needed</code></a> 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 <a class="external" href="http://irc.mozilla.org/developers">#developers</a> de <a class="external" href="http://irc.mozilla.org/">irc.mozilla.org</a> (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.</p>
+
+<p>Si vous publiez vous même, suivez les <a href="/en-US/docs/Developer_Guide/Committing_Rules_and_Responsibilities" title="/en-US/docs/Developer Guide/Committing Rules and Responsibilities">Règles de publication et de responsabilité</a>.<br>
+ Nous recommendons l'utilisation de <a href="https://moz-conduit.readthedocs.io/en/latest/lando-user.html">Lando</a> (en) pour que le code soit automatiquement envoyé.</p>
+
+<h2 id="Getting_the_patch_checked_into_the_tree" name="Getting_the_patch_checked_into_the_tree">Régressions</h2>
+
+<p>Il se pourrait que votre code provoque des régressions fonctionnelles ou une baisse de performance. il y a une <a class="external" href="http://www.mozilla.org/hacking/regression-policy.html" title="http://www.mozilla.org/hacking/regression-policy.html">politique</a> 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.</p>
+
+<p>Après la création de quelques correctifs, envisagez d'<a href="http://www.mozilla.org/hacking/committer/" title="http://www.mozilla.org/hacking/committer/">avoir accès au code source de Mozilla</a> (en).</p>