First, let me state that I am generally in support of this type of change. More comments below.
On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor <mcon...@mozilla.com> 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. > > I think this is a good long-term goal, but I don't think it's one we need to achieve now. At the moment, I would settle for "only a few privileged people can single-handedly land malicious code into our products". In support of this, I would note that what you propose below is insufficient to achieve your stated objective, because there will still be single person admin access to machines. > - 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. > > I think this is a good eventual goal, but in the short term, I think it's probably useful to keep checkin-needed floating around, especially given the somewhat iffy state of the toolchain. > > - 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. > > Implicit in this is some sort of hierarchy of reviewers (tied to what was previous L3 commit?) that says who can review a patch. Otherwise, I can just create a dummy account, r+ my own patch, and Land Ho! IIRC Chromium does this by saying that LGTM implies autolanding only if the reviewer could have landed the code themselves. -Ekr > - 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 > > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > _______________________________________________ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
