On Tue, Mar 9, 2010 at 9:39 PM, David Levin <span dir="ltr">&lt;<a href="mailto:levin@chromium.org">levin@chromium.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  (3) Someone reviewed an earlier version of the patch but then didn&#39;t<br>
follow up.  I think having a partial review by one person encourages<br>
other people to assume that person will finish the review.  That cause<br>
the patch to float upwards in pending-review until it gets lost in the<br>
sea of ancient patches.  I&#39;d encourage reviewers to follow through<br>
with their reviews</blockquote></div><div> ....</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Don&#39;t be afraid of r-ing a patch.  Believe me,<br>


folks are thankful for feedback (even negative feedback) when their<br>
patches have been sitting around collecting dust.<br></blockquote><div><br></div></div><div>However as soon as you r- a patch, according to &quot;3&quot;, you need to finish the review when it gets re-submitted. This leads me to believe that <i>one shouldn&#39;t avoid a patch that has feedback from someone else</i> unless one doesn&#39;t feel qualified to judge whether the feedback has been addressed.</div>


<div><br></div><div>I plea to folks submitting patches: </div><div>1. Keep your patches as small as possible. It is no fun to deal with a 60K patch.</div><div>2. Review your own patches before or right after you attach them to the bug as if you were reviewing someone else&#39;s code.</div>


<div>3. Address any style issues, build issues that the bots notice. You don&#39;t need to wait for a review to point out the same issue.</div></div></blockquote><div><br></div><div>It&#39;s also a big help when peers (which aren&#39;t necessarily WebKit reviewers) look over it and give review-style feedback as well.  Especially when said peers know more about that code than any of the official reviewers.</div>

</div>