Re: The future of commit access policy for core Firefox

On 09/03/2017 22:59, Bobby Holley wrote:
> Also, getting rid of "r+ with comments" is a non-starter.

+ a lot on this.

I think part of the trust implicit in granting of commit access, and the 
reviewer's discretion/trust of the patch author, and said author's 
ability to correctly deal with comments without requiring the reviewer 
to have another look, mean that removing "r+ with comments" ought not to 
be a goal.

If the reviewer doesn't trust the author (from either an ability or 
intent perspective) to fix the comments, they shouldn't give "r+ with 
nits fixed".

If we don't trust the author to not 'sneak in' unrelated changes off an 
r+'d patch, we ought not to give them commit access.

~ Gijs

>
> bholley
>
>
> On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor <[email protected]> wrote:
>
>> (please direct followups to dev-planning, cross-posting to governance,
>> firefox-dev, dev-platform)
>>
>>
>> Nearly 19 years after the creation of the Mozilla Project, commit access
>> remains essentially the same as it has always been.  We've evolved the
>> vouching process a number of times, CVS has long since been replaced by
>> Mercurial & others, and we've taken some positive steps in terms of
>> securing the commit process.  And yet we've never touched the core idea of
>> granting developers direct commit access to our most important
>> repositories.  After a large number of discussions since taking ownership
>> over commit policy, I believe it is time for Mozilla to change that
>> practice.
>>
>> Before I get into the meat of the current proposal, I would like to outline
>> a set of key goals for any change we make.  These goals have been informed
>> by a set of stakeholders from across the project including the engineering,
>> security, release and QA teams.  It's inevitable that any significant
>> change will disrupt longstanding workflows.  As a result, it is critical
>> that we are all aligned on the goals of the change.
>>
>>
>> I've identified the following goals as critical for a responsible commit
>> access policy:
>>
>>
>>    - Compromising a single individual's credentials must not be sufficient
>>    to land malicious code into our products.
>>    - Two-factor auth must be a requirement for all users approving or
>>    pushing a change.
>>    - The change that gets pushed must be the same change that was approved.
>>    - Broken commits must be rejected automatically as a part of the commit
>>    process.
>>
>>
>> In order to achieve these goals, I propose that we commit to making the
>> following changes to all Firefox product repositories:
>>
>>
>>    - Direct commit access to repositories will be strictly limited to
>>    sheriffs and a subset of release engineering.
>>       - Any direct commits by these individuals will be limited to fixing
>>       bustage that automation misses and handling branch merges.
>>    - All other changes will go through an autoland-based workflow.
>>       - Developers commit to a staging repository, with scripting that
>>       connects the changeset to a Bugzilla attachment, and integrates
>> with review
>>       flags.
>>       - Reviewers and any other approvers interact with the changeset as
>>       today (including ReviewBoard if preferred), with Bugzilla flags as
>> the
>>       canonical source of truth.
>>       - Upon approval, the changeset will be pushed into autoland.
>>       - If the push is successful, the change is merged to mozilla-central,
>>       and the bug updated.
>>
>> I know this is a major change in practice from how we currently operate,
>> and my ask is that we work together to understand the impact and concerns.
>> If you find yourself disagreeing with the goals, let's have that discussion
>> instead of arguing about the solution.  If you agree with the goals, but
>> not the solution, I'd love to hear alternative ideas for how we can achieve
>> the outcomes outlined above.
>>
>> -- Mike
>> _______________________________________________
>> dev-planning mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-planning
>>