Gerrit/Code review/Getting reviews/fr


 * Pour apprendre comment relire le code des autres contributeurs consultez le tutoriel et le Guide de la relecture de code.

Comment faire pour que vos modifications de code soient relues plus rapidement et aient plus de chance d'être acceptées ?

Prérequis

 * Vous avez modifié du code pour corriger un bogue ou ajouter une nouvelle fonctionnalité.
 * Vous avez suivi les Conventions de codage.
 * Vous avez suivi la Liste des contrôles à faire avant la validation.
 * Vous avez suivi les.
 * Vous devez utiliser un avec Gerrit et configurer Git / Gerrit sur votre machine avec succès.

Maintenant vous envisagez d'écrire une correction à téléverser dans Gerrit pour que son code soit relu et fusionné (c'est à dire intégré à la base de code).



Votre correction


Vérifier au préalable qu'elle répond au sujet
Si le code que vous proposez ne corrige pas un bogue mais qu'il introduit une nouvelle fonctionnalité, parlez-en d'abord avec le mainteneur pour être sûr que votre idée est conforme avec les objectifs du projet et que l'approche technique que vous proposez est la solution optimale. Ceci économise votre temps et ...une déception potentielle.



Testez vos modifications
Testez vos modifications dans votre environnement de développement pour vérifier qu'il n'y a pas d'erreurs de compilation ni de tests en échec. Si vous n'avez pas testé votre patch pour une raison quelconque, dites le explicitement dans un commentaire de Gerrit. Suivez ensuite la Liste des contrôles à faire avant la validation.

Evitez de fournir des corrections incomplètes et d'introduire de nouveaux bogues. Si vous savez déjà que votre correction a besoin de plus de travail, dites le explicitement dans Gerrit avec un  lors de la relecture ou en préfixant le message de validation (commit) avec   (work in progress).



Faites des validations courtes
Des corrections petites, indépendantes et complètes ont plus de chance d'être acceptées.

Si vos validations concernent plusieurs fichiers qui ne sont pas fortement dépendants, il est préférable de les séparer en les regroupant en plusieurs validations plus petites.

En plus, assurez-vous de ne pas inclure de modifications inutiles dans votre correction (par exemple en corrigeant le style du code).

Néanmoins, si vos validations se répètent sur les mêmes fichiers, rassemblez-les en une grande validation (en utilisant soit  ou en les écrasant après cela).



Rédigez un message de validation significatif
Le message de validation doit expliquer quoi ? et pourquoi ?. Quel était le problème ? Comment la correction résout-elle le problème ? Comment tester qu'elle fonctionne effectivement ? Voir pour plus d'informations.

Egalement, assurez-vous de relire et d'utiliser dans votre message de validation, le vocabulaire adapté et la ponctuation.



Fournissez la documentation
Si une fonctionnalité dans votre correction doit être visible des utilisateurs finaux ou des administrateurs, vérifiez la mise à jour ou créez la documentation associée. Voir la Politique de la documentation pour plus d'informations.



Ne mélangez pas les rebase avec les modifications
Si vous devez rebaser, ne faites que le rebase. Si des modifications qui ne concernent pas le rebase sont faites dans une action de rebase  de corrections, vous devrez relire beaucoup plus de code pour les retrouver, et cela n'est pas du tout évident. Lorsque vous faites une modification importante, laissez un commentaire Gerrit pour expliquer son action et relisez le résumé de la validation pour vérifier qu'il est encore actuel.



Votre activité


Répondez aux tests en faute et aux commentaires
Vérifiez vos paramètres Gerrit et assurez-vous de recevoir les notifications par courriel. Si votre code échoue aux tests automatisés, ou que vous avez déja été relu, répondez dans un commentaire ou soumettez à nouveau.

(Pour connaître la cause de l'échec des tests automatiques, cliquez sur le lien du commentaire failed dans Gerrit, survolez avec la souris le point rouge du test en échec, attendez que la fenêtre de popup apparaisse, puis cliquez sur la sortie console (console output).)

Les commentaires viendront habituellement (mais pas toujours) de Gerrit avec une marque C-2, C-1, C+1, ou C+2. Vous trouverez les détails de ces explications (du point de vue du relecteur) sur Finaliser la relecture de code. Certains relecteurs peuvent proposer des suggestions d'amélioration sans utiliser explicitement un C-1 pour rassurer les nouveaux contributeurs. Vous devez encore prendre sérieusement en considérations leurs suggestions.

Quelques fois vous recevrez des appréciations que vous considérerez comme inadaptées, par exemple ayant trait à l'esthétique du code. Ne les ignorez pas mais reprenez votre correction pour répondre aux demandes triviales : vous pouvez être en désaccord mais en discutant vous perdrez plus de temps que si vous aviez accepté le point.

La relecture du code est une partie de la construction du consensus, et non pas une course aux élections. Vous êtes supposé répondre à un commentaire négatif, n'essayez pas de le contredire en apportant des commentaires positifs supplémentaires. Répondre à un commentaire négatif n'oblige pas toujours de modifier sa correction : quelques fois une meilleure explication est suffisante. Néanmoins même dans ces cas il peut être utile d'incorporer ces explications dans le message de validation ou dans les commentaires du code pour mieux informer les mainteneurs futurs à propos du même problème.

En général : soyez patient et grandissez un peu ! Les collaborateurs les plus expérimentés qui soumettent leurs corrections reçoivent plus rapidement des réponses positives.



Ajoutez des relecteurs
Le choix des relecteurs joue un rôle important dans le temps de relecture. Les relecteurs les plus actifs fournissent les réponses les plus rapides.

Juste après votre validation ajoutez un ou deux développeurs à la correction pour la relecture. (Ce sont des demandes – il n'y a pas de moyen pour assigner une relecture à une personne particulière dans Gerrit.) Les développeurs expérimentés devraient aider à ce propos : si vous observez qu'il reste des modifications non relues, ajouter leur des relecteurs. Pour trouver des relecteurs :


 * Regardez la liste principale des mainteneurs, ou les mainteneurs listés sur la page de l'extension, afin de trouver qui s'occupe actuellement de la maintenance de cette partie de code, ou qui est en formations pour la maintenance.
 * Cliquez sur l'icône de la loupe se trouvant sur la ligne Project de votre correction Gerrit. Puis cherchez les autres corrections de ce dépôt : les personnes qui écrivent et qui relisent ces corrections sont de bons candidats à ajouter comme relecteurs. Ou bien affichez qui peut approuver votre correction : cliquez sur Access dans la barre de navigation supérieure, cliquez sur le ou les liens des lignes Owners, pour voir la liste des noms.
 * To find out who added a system message and why, see Gerrit/Navigation#System messages for specific advice.
 * Recherchez les résumés des autres validations et des corrections. Navigate the repository tree to your repository or directory and click "View History" to see who is active in the area, for instance changes in the database of MediaWiki core. Or search on Gerrit: Matma Rex and Foxtrott are interested in reviewing frontend changes, so you can search for "message:css" to find changesets that mention CSS in their commit summaries to add them to. Vous pouvez utiliser ceci ainsi que les expressions régulières pour trouver les modifications qui accèdent aux mêmes composants que ceux que vous avez touchés, ou pour trouver des relecteurs similaires (documentation de recherche).



Relisez davantage de corrections
Many eyes make bugs shallow. Read the Code review guide and help other authors by praising or criticizing their commits. Comments are nonbinding, won't cause merges or rejections, and have no formal effect on the code review. But you'll learn by reviewing, gain reputation, and get people to return the favor by reviewing your proposed code changes in the future. "How to review code in Gerrit" has the step-by-step explanation.



Comment résoudre les obstacles éventuels


Pas de commentaire temporisé
Les ressources humaines dans les projets logiciels à source libre sont limitées et les intérêts des développeurs peuvent évoluer. Certains dépôts de code sont plus actifs et maintenus que d'autres et vous recevrez les relectures plus rapidement. D'autres domaines ont une politique de maintenance pas très bien définie, ou même ils ont été abandonnés et vous pourriez encore attendre longtemps.

Vous pouvez voir les dernières activités du dépôt de code en affichant la liste des Validations récentes dans Diffusion ou via  sur votre copie locale. Pour reprendre en main un projet abandonné et devenir son mainteneur, suivez ces étapes.

If you think that your patch has been gone unnoticed for a longer time, feel free to bring up the problem on the IRC channel.



Autres raisons de restructurer le code ou de le rejeter
Even if you have followed all recommendations, your patch might still require some rework (or in rare cases even get rejected).

Apart from what has been mentioned already, there are more potential reasons for rejection (not all of them are equally decisive), such as a suboptimal solution when there is a more simple or efficient way, performance issues, security issues, improvable naming (e.g. of variables), integration conflicts with existing code, duplication of work, unintended (mis)use of the API, or proposed changes to internal APIs being considered too risky.

Be aware that there is a mismatch of judgement: Patch reviewers often consider test failures, an incomplete fix, introducing new bugs, a suboptimal solution, and inconsistent docs way more decisive for rejecting a patch than patch authors.



Voir aussi

 * 5 conseils pour que votre code soit relu plus rapidement
 * Notes des réunions de relecture du code - depuis 2012; les parties concernées sont dorénavant incluses dans la présente documentation