Development/gerrit/PatchReview/pt-br

TDF LibreOffice Brasil Document Liberation Project Community Blogs Traduções Nextcloud Redmine Perguntas e respostas Doar

• Início
• Desenvolvimento
• Design
• Controle de Qualidade (QA)
• Events
• Documentação
• Website
• Localização
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Visão geral
• Relatando erros
• Como compilar
• Visão geral do código
• Comandos do Git
• Depuração
• Hacks fáceis
• Planejamento de versões
• Perguntas frequentes
• Desenvolvedores
• Extensions
• → Open Issues

Depois de completar o setup do gerrit, e você ou outros colegas submeteram patches, você pode começar a revisar patches no gerrit.

Buscando patches à espera de revisão

./logerrit query status:open

mostrará todos os patches à espera de revisão. Veja a documentação gerrit para saber das coisas legais que você pode fazer a mais (criar scripts, etc...).

Obter um patch

./logerrit cherry-pick CHANGEID

sendo o CHANGEID mostrado na saída da consulta ao gerrit

Updating patch

If you found and fixed a problem during review. You might update the existing patch in gerrit the following way:

git status; git diff

which makes sure that you have only the single cherry-picked commit and the extra changes on top

git commit -a --amend

which updates the last commit locally

./logerrit submit

which pushes all uncommited changes into gerrit; it updates the existing patch in gerrit if the ID stayed the same in the commit message

Comment and Approve

If you want to add comments or approve the patch, the best way is to do it from the Gerrit web interface. Comment by clicking a line of a changed file and when you are done click the Reply... link to publish your review.

Alternatively, you might just push the patch but it will not add the nice comments about reviewing.

Use of Code-Review and Verified

If you look at your patch on Gerrit you will see two status codes:

• Code-Review
• Verified

The reviewers, our CI system (jenkins) and potentially yourself will use these two fields to qualify the patch.

Code-Review

Can be assigned −2, −1, 0, +1, +2

−2 are to be used by the author, to signal “work in progress”. The −2 prevents the patch from being merged, and only the person who issued the −2 can remove it.

If you work on a larger patch, you are most welcome to upload a patch, mark it as −2, to see if it builds successfully on all platforms

−1 is used by the reviewer, if there are things in the patch that should be changed

0 is used when making comments, that has no effect on whether or not the patch should be merged.

+1 is used by the reviewer, to signal the patch is ok, but the reviewer would like a second opinion

+2 is used by the author to signal no review is needed (this can only be done by core developers, and should be used with care). The person who merges your patch, will use +2, just before merging, since only +2 can be merged. The ability to set +2 depends on the push rights of the reviewer. These rights are conferred individually.

Remark, a patch will NOT be merged as long as there are −1 or −2 unresponded to.

Verified

Can be assigned −1, 0, +1

−1 is used by the CI system if the build fails (note that this is not always a problem in your patch, but can be due to a broken master).

−1 is used by the reviewer, if the expected result cannot be seen.

0 is used when making comments, that has no effect on whether or not the patch should be merged.

+1 is used by the CI system if the build is successful

+1 is used by the reviewer, when the expected result has been verified.

Remark, a patch will NOT be merged unless the CI system shows a successful build.

Note: For more information on those labels, see the gerrit documentation. For gerrit configuration relevant to our projects, see Access Control Lists for all dev-related repositories, for core, and for all other projects.