Mike Connor 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.
>
>
Aside for the first one, the other items seem to be mere
'implementation/application details', rather than actual goals.
- Protect Firefox repositories to the best of our abilities and
resources availability by implementing a set of rules and factors
to prevent unauthorized access/modifications to the core content.
> In order to achieve these goals, I propose that we commit to making the
> following changes to all Firefox product repositories:
By all Firefox product repositories, I'm assuming mainly m-*,
and integration/m-i?
And with this new proposed process, this means the doing away
of integration/m-i as it would be superfluous if an autoland-esque
repo is used.
What about other repositories? Tier 2, etc.. i.e. comm-*?
>
>
> - 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.
So m-i is obsoleted. Autoland is the defacto push repo?
1) Developer submits a patch to bugzilla or reviewboard
2) it gets reviewed and/or approved
3) it then gets pushed to autoland [tbh, I don't know how autoland
works, so does someone push to autoland, or does bugzilla do it
for us? -rhetorical question.. can find out off-list]
4) sheriffs watch the autoland tree and backout whatever bustages
happen and every so often, they merge autoland to m-c. If
patches need to be uplifted, they are done by sheriffs.
So we're pretty much back to the similar vein of m-* and
mozilla-inbound (except now, it's autoland).
Is this the gist of it?
Edmund
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
