Gerrit Caveats and Hints: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
=Gerrit Caveats and Hints=
[[Category:Developing_Qt::Guidelines]]


===Dos and Don’ts===
= Gerrit Caveats and Hints =


* Do not reply to review comments by mail. It hurts collaboration (as the mails are not publicaly archived). The correct way is hitting the “review” button and adding followup comments. If you want to reply to particular inline comments, open the diff view for the patchset the comments pertain to and use the reply buttons there (note that you still need to use the “review” button (of the right patchset!) to actually submit the comments).
=== Dos and Don'ts ===
* As an author, do not rebase your commits unless necessary, as that makes inter-patchset-diffs completely useless. Use rebase -i <span class="caps">HEAD</span>~n rather than rebase -i @{u} when you reshuffle commits and you fetched origin meanwhile. Do not pull for no good reason. When you rebased, try to push as little as possible (<span class="caps">HEAD</span>~n:refs/for/foo) to avoid invalidating previous reviews.
* When you make multiple unrelated commits, it is best to throw away (reset —hard <span class="caps">HEAD</span>~n) the already pushed ones or make a new branch for each “topic”. That way it is easier to amend commits without invalidating unrelated reviews.
* As a reviewer, do not be too trigger-happy with the “stage” button. Allow other reviewers to do their job as well, especially when domain experts were invited.
* Don’t do “fake” reviews. If you cannot honestly give a +2 (i.e., “I fully understand that patch and its implications, and I take the blame if it breaks”), then don’t. If needed, refer to the Maintainer Priviledge codified in the [[Commit-Policy|Commit Policy]].


===Useful Gerrit Queries===
* Do not reply to review comments by mail. It hurts collaboration (as the mails are not publicaly archived). The correct way is hitting the &quot;review&amp;quot; button and adding followup comments. If you want to reply to particular inline comments, open the diff view for the patchset the comments pertain to and use the reply buttons there (note that you still need to use the &quot;review&amp;quot; button (of the right patchset!) to actually submit the comments).
* As an author, do not rebase your commits unless necessary, as that makes inter-patchset-diffs completely useless. Use rebase -i HEAD~n rather than rebase -i <code>{u} when you reshuffle commits and you fetched origin meanwhile. Do not pull for no good reason. When you rebased, try to push as little as possible (HEAD~n:refs/for/foo) to avoid invalidating previous reviews.
* When you make multiple unrelated commits, it is best to throw away (reset —hard HEAD~n) the already pushed ones or make a new branch for each &quot;topic&amp;quot;. That way it is easier to amend commits without invalidating unrelated reviews.
* As a reviewer, do not be too trigger-happy with the &quot;stage&amp;quot; button. Allow other reviewers to do their job as well, especially when domain experts were invited.
* Don't do &quot;fake&amp;quot; reviews. If you cannot honestly give a +2 (i.e., &quot;I fully understand that patch and its implications, and I take the blame if it breaks&amp;quot;), then don't. If needed, refer to the Maintainer Priviledge codified in the [[Commit Policy]].


[https://codereview.qt.io/#q,-CodeReview=-1+-CodeReview=-2+-CodeReview=2+is:open,n,z Gerrit tasks missing (+2) review] ''[codereview.qt.io]''”
=== Useful Gerrit Queries ===
 
===Categories:===
 
* [[:Category:Developing Qt|Developing_Qt]]
** [[:Category:Developing Qt::Guidelines|Guidelines]]

Revision as of 10:23, 24 February 2015


Gerrit Caveats and Hints

Dos and Don'ts

  • Do not reply to review comments by mail. It hurts collaboration (as the mails are not publicaly archived). The correct way is hitting the "review&quot; button and adding followup comments. If you want to reply to particular inline comments, open the diff view for the patchset the comments pertain to and use the reply buttons there (note that you still need to use the "review&quot; button (of the right patchset!) to actually submit the comments).
  • As an author, do not rebase your commits unless necessary, as that makes inter-patchset-diffs completely useless. Use rebase -i HEAD~n rather than rebase -i {u} when you reshuffle commits and you fetched origin meanwhile. Do not pull for no good reason. When you rebased, try to push as little as possible (HEAD~n:refs/for/foo) to avoid invalidating previous reviews.
  • When you make multiple unrelated commits, it is best to throw away (reset —hard HEAD~n) the already pushed ones or make a new branch for each "topic&quot;. That way it is easier to amend commits without invalidating unrelated reviews.
  • As a reviewer, do not be too trigger-happy with the "stage&quot; button. Allow other reviewers to do their job as well, especially when domain experts were invited.
  • Don't do "fake&quot; reviews. If you cannot honestly give a +2 (i.e., "I fully understand that patch and its implications, and I take the blame if it breaks&quot;), then don't. If needed, refer to the Maintainer Priviledge codified in the Commit Policy.

Useful Gerrit Queries