Re: The future of commit access policy for core Firefox
Justin Dolske <[email protected]> Mon, 13 Mar 2017 12:48:46 -0700
| Newsgroups | gmane.comp.mozilla.devel.seamonkey |
|---|---|
| Organization | Mozilla Corporation |
| Message-ID | <[email protected]> |
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