[webkit-dev] Sunsetting committership and reviewership

[Ryosuke Niwa]

On Mon, Apr 8, 2013 at 10:36 AM, Benjamin Poulain <benjamin at webkit.org>wrote:

> On Mon, Apr 8, 2013 at 1:45 AM, Simon Hausmann <simon.hausmann at digia.com>wrote:
>>
>> And instead of addressing these reviewers directly we are trying to
>> introduce
>> a process to automate this, avoid the confrontation, hope that reviewers
>> accepting bad ideas today will instead expire in the future.
>>
>> It appears to me that this approach is based on the assumption that trust
>> fades away over time. Naturally this perception may differ from person to
>> person.
>>
>
> In my opinion, reviews are not "trust affair", they are a technical
> decision. You seem to think people intentionally review bad thinks, I don't
> agree.
>

> When I mess up a review, it is because of the illusion of knowledge. I
> believed I knew enough about a subject to review a patch, but my knowledge
> was outdated or erroneous. With time, this problem becomes worse. I believe
> I know the code, but I only know the past version of the code.
> With hundreds of patches a day, I think not contributing for 2 years means
> you have an outdated view of the code.
>

+1 to that.

When I make bad reviews (I do!), I don't often realize it until bugs are
filed for regressions or some other more knowledgable reviewers comment on
the bug, pointing out flaws in the patch.

In a way, this is an unsolvable problem because nobody can possibly know
with a 100% certainly if you're qualified to review a patch or not.  I've
reviewed some patches that are clearly outside of my expertise at times
because there were no active reviewers in that area, etc... It's a hard
judgement call. On one hand, we don't want to block patches forever
especially it's a crash or security vulnerability fix. On the other hand,
we shouldn't be reviewing patches just because we want to be nice to our
colleague.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130408/41bb83e7/attachment.html>