On Mon, Apr 8, 2013 at 10:36 AM, Benjamin Poulain <benja...@webkit.org>wrote:
> On Mon, Apr 8, 2013 at 1:45 AM, Simon Hausmann > <simon.hausm...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
