[webkit-dev] Why I'm reviewing patches outside my area (and why you should too)

Jeremy Orlow jorlow at chromium.org
Tue Mar 9 13:51:18 PST 2010


On Tue, Mar 9, 2010 at 9:39 PM, David Levin <levin at chromium.org> wrote:

>
>>  (3) Someone reviewed an earlier version of the patch but then didn't
>> follow up.  I think having a partial review by one person encourages
>> other people to assume that person will finish the review.  That cause
>> the patch to float upwards in pending-review until it gets lost in the
>> sea of ancient patches.  I'd encourage reviewers to follow through
>> with their reviews
>
>  ....
>
>> Don't be afraid of r-ing a patch.  Believe me,
>> folks are thankful for feedback (even negative feedback) when their
>> patches have been sitting around collecting dust.
>>
>
> However as soon as you r- a patch, according to "3", you need to finish the
> review when it gets re-submitted. This leads me to believe that *one
> shouldn't avoid a patch that has feedback from someone else* unless one
> doesn't feel qualified to judge whether the feedback has been addressed.
>
> I plea to folks submitting patches:
> 1. Keep your patches as small as possible. It is no fun to deal with a 60K
> patch.
> 2. Review your own patches before or right after you attach them to the bug
> as if you were reviewing someone else's code.
> 3. Address any style issues, build issues that the bots notice. You don't
> need to wait for a review to point out the same issue.
>

It's also a big help when peers (which aren'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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100309/d7d3a73f/attachment.html>


More information about the webkit-dev mailing list