Re: The future of commit access policy for core Firefox

Count me as another one skeptical about adding a review step. (I work 
most closely with someone 8 hours off of my timezone; I'd bet there's a 
correlation between opinions on final review vs timezone offsets.)

The most promising option in my mind would be to (1) improve tooling on 
interdiffs, and then (2) automatically post an interdiff to the bug 
*after* it lands. Then we could choose whether that final interdiff 
requires review or whether it's just an FYI. It doesn't prevent someone 
from sneaking in some huge security hole, but it makes it a lot more 
visible and obvious when they do -- which provides some amount of 
discouragement from it happening in the first place. For slightly more 
visibility, you could post all of these ex post facto interdiffs to some 
easily-skimmable place.

IIUC, we're trying to scale here. One problem with scaling is that there 
are more cracks to sneak security flaws into. Another is scaling the 
rate of changes landing in the tree. More process helps the first and 
hurts the second, so we need to find a balance. I submit that ex post 
facto interdiffs are a reasonable point of tradeoff.

Obviously, anything we could do to help *both* sides of the equation 
would be great. That includes better interdiffs and the autoposted nit 
interdiffs, both of which would be useful even without process changes. 
(I'm guessing that scanning a stream of nit interdiffs would point 
towards some tooling improvements that could eliminate the need for a 
fair number of final touch-ups.)

If we *do* end up requiring a review on the final version, whether 
retroactive or blocking, we could also reduce the friction slightly via 
tooling that allows comment changes through. Maybe even variable renames 
or formatting changes. But I doubt that changes the overall picture 
significantly.