+1 for these proposed changes 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. > - 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 > dev-plann...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-planning > -- Benjamin Kerensa _______________________________________________ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
