(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
_______________________________________________
governance mailing list
governance@lists.mozilla.org
https://lists.mozilla.org/listinfo/governance
