Re: The future of commit access policy for core Firefox

On Mon, Mar 13, 2017 at 6:36 AM, Boris Zbarsky <[email protected]> wrote:

> On 3/12/17 9:55 PM, Eric Rescorla wrote:
>
>> Alternately, you can create a patch which gets r+ with nits, and
>> then update with some malicious code and  r=<committer>.
>>
>
> Speaking as a reviewer, for people I don't trust I pretty much never give
> "r+ with nits", because I don't trust them to address the nits correctly.
>

Actually, I wish I had written this differently. Say I get an r+ w/o nits,
I suspect
that the sheriffs will accept an updated patch (e.g., ostensibly with a
comment
fix) that is marked r=<foo>.


So, I would ask: do people believe that this is an acceptable state of
>> affairs or should the minimum number of 'trusted' people required to land
>> a patch be 1
>> or more?
>>
>
> Obviously the latter.  ;)


Me too. And I think "trust" in this case at least arguably should be
defined as
"trusted by Mozilla" (e.g., L3 committer). So, one possibility would be
have a
policy like the following.

- Every CL must either be written by someone trusted OR r+ed by someone
trusted.
- If a patch is r+ with nits, then the final patch must be posted by someone
trusted.

This would ensure that every CL that lands was signed off on in its final
form
by a someone trusted.

Does this seem crazy?

-Ekr


>
>
> -Boris
>
>
> _______________________________________________
> dev-planning mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-planning
>