From:  Justin Dolske <dolske@mozilla.com>
Date:  14 Mar 2017 03:48:46 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.planning
Subject:  

Re: The future of commit access policy for core Firefox

NNTP-Posting-Host:  63.245.221.32

On 3/12/17 5:44 PM, Daniel Veditz wrote:

> That assumes the developers you review have good intentions--which is
> almost always true. Like most security-inspired restrictions, however,
> the worry is about someone with bad intentions. It's similar to
> insurance in that you pay every year but really you hope that your house
> does NOT burn down, but in that case it feels like a waste.

Along those lines, it seems worthwhile to note (and I haven't seen this 
raised yet?) that at the core this is also a human-factors problem, and 
those are notoriously difficult to fix with technology.

Specifically, here: if a reviewer has already decided that a patch is 
"r+ with fixes", it's unlikely that the followup patch is going to get a 
vigorous, detailed review. Especially if the process is perceived as 
pointless overhead, causing delays, and 99.9999% of the time the patch 
author is not trying to sneak in malicious code.

So a simple "every patch must be reviewed" requirement which doesn't 
address that in some way isn't really going to change much from the 
status quo -- you'd get "reviews", but only as a paperwork formality.

To improve that, we'd need to do things like asking what it would take 
to have reviewers give "r+ with fixes" less often, understanding if the 
risk can be mitigated (by more/less trust in some authors), etc.

> No easy answers.

Indeed.

Justin