Adopting the mozilla-central superreview policy in comm-central

Dan Mosedale dmose at
Fri Jun 11 17:44:57 UTC 2010

  On 6/10/10 4:02 PM, Karsten Düsterloh wrote:
> Dan Mosedale aber hob zu reden an und schrieb:
>>> Actually, I find this policy change strange, to say the least. I'd
>>> say that TB needs - no offence meant! - more reviewing, not less.
>>> I'm aware that reviewers as such are a scarce resource, but (as I
>>> said before) you can't exchange competence by automation...
>> I guess I'm not convinced that "more" versus "less" really captures
>> the nuance of the change that's on the table here.
> Well, not in the strict sense of words. 10 people looking at something
> they don't fully grasp instead of 1 surely won't help.
While the above sentence is strictly true, it's not clear to me in what 
way it applies to the situation at hand.
> Certain classes of potential bugs are just invisible to the less
> experienced. Hence they _can't_ and won't request further
> (super-)review, because they don't even know there's a problem!
Even if the patch authors are not in a position to recognize when more 
review is advantageous, I would expect that most of the time, reviewers 
will be.
>> In particular, it seems to me an attempt to focus the reviewing eyes
>> where they're _most_ needed, rather than trying to blanket a
>> too-large-code-base using insufficient resources.
> I just doubt that exchanging quality by throughput is helping.
The above sentence doesn't seem to capture the fact that we're trying to 
trade acceptance of more risk in areas that don't have broad effects 
(localized changes) in exchange for less risk in areas that do 
(cross-module, API, and refactoring changes).
>> Given that anyone (patch author or reviewer) can and should be asking
>> for second reviews when appropriate,
> How would they know? (See above.)
Some patch authors will, and I would expect most reviewers to know more 
of the time.  But the fact that we're interested in accepting risk only 
in areas with less far-reaching changes is what makes this change a good 


More information about the tb-planning mailing list