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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform