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.