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.

Now you plan to create a patch to upload to Gerrit to get your code reviewed and merged (included in the code base).



Votre correction


Vérifier au préalable qu'elle répond au sujet
If your proposed code changes do not fix a bug but introduces a new feature instead, speak first to the maintainers to make sure that your idea is in the project scope and that your proposed technical approach is the optimal solution. Ceci vous économise du temps et une déception potentielle.



Testez vos modifications
Testez vos modifications dans votre environnement de développemnt 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. If you know that your patch needs more work, explicitly say so in Gerrit by reviewing it as "-2" or adding a "[WIP]" (work in progress) prefix to the commit message.



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

If your commits are going to be touching separate files and there's not a lot of dependency between them, it's probably best to keep them as smaller discrete commits.

Furthermore, make sure to not include unnecessary changes in your patch (e.g. fixing the coding style).

However, if your commits are going to be touching the same files repeatedly, bundle them up into one large commit (using either  or squashing after the fact).



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 prolbème ? Comment tester qu'elle fonctionne effectivement ? Voir pour plus d'informations.

Also, make sure to proofread and use proper spelling and punctuation in your commit message.



Fournissez la documentation
If a feature in your patch is going to be visible to end users or administrators, make sure to update or create related documentation. 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. If non-rebase changes are made inside a rebase changeset, you have to read through a lot more code to find it and it's non-obvious. When you're making a real change, leave a Gerrit comment explaining your change, and revise your commit summary to make sure it's still accurate.



Votre activité


Répondez aux tests en faute et aux commentaires
Check your Gerrit settings and make sure you're getting email notifications. If your code fails automated tests, or you got some review already, respond to it in a comment or resubmission.

(To see why automated tests fail, click on the link in the "failed" comment in Gerrit, hover over the failed test's red dot, wait for the popup to show, and then click "console output.")

Feedback will usually (but not always) come with a C-2, C-1, C+1, or C+2 flag from Gerrit. You can read more about what these mean (from the reviewer's perspective) at Gerrit/Code review#Complete the review. Some reviewers will offer suggestions for improvement without using an explicit C-1 rating in order to reassure new contributors. Vous devez encore prendre sérieusement en considérations leurs suggestions.

Sometimes you'll receive reviews which you'll perceive as irrelevant, for instance merely cosmetic. Do not ignore such reviews but amend your patch to satisfy trivial requests: You may disagree, but discussing costs time and is more expensive than conceding a point.

La relecture du code est une partie de la construction du consensus, et non pas une course aux élections. You are expected to address negative feedback, not "outvote it" by seeking additional positive reviews. Addressing negative feedback does not always require changes to your patch: sometimes all that is required is a better explanation. However, even in those cases it can be useful to incorporate those explanations into the commit message or comments in the code to better inform future maintainers with the same concerns.

In general: Be patient and grow. 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. (These are requests – there's no way to assign a review to one specific person in Gerrit.) Experienced developers should help with this: if you notice an unreviewed changeset lingering, then please add reviewers. To find reviewers:


 * Check the main maintainers list, or the maintainers listed in the extension's page, to find who's currently maintaining that part of the code, or is in maintainer training.
 * Click the magnifying glass in the "Project" row of your Gerrit patch. Now find other changesets in that repository: the people who write and review those changesets would be good candidates to add as reviewers. Or see who can approve your patch: click "Access" in the top navigation bar, click the link(s) in "Owner" rows, see the list of names.
 * To find out who added a system message and why, see Gerrit/Navigation#System messages for specific advice.
 * Search through other commit summaries and changesets. 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. You can use this and regexes to find changes that touch the same components you're touching, to find likely reviewers (search docs).



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é
Manpower in free and open source software projects is limited, and interests of developers may change. Certains dépôts de code sont plus actifs et maintenus que d'autres et vous recevrez les relectures plus rapidement. Other areas have unclear maintainership or are even abandoned and you might have to wait for a long time.

You can check the latest activity in a code repository by looking at the "Recent Commits" list of the repository in Diffusion or via  in your local checkout. To take over an abandoned project and become its maintainer, follow these steps.

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