<div dir="ltr">First, let me state that I am generally in support of this type of change.<div><br></div><div>More comments below.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor <span dir="ltr"><<a href="mailto:mconnor@mozilla.com" target="_blank">mconnor@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span id="m_-3670080503921479195gmail-docs-internal-guid-35bbe6a8-b500-3db2-d62d-4f874a83e6d6"><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">(please direct followups to dev-planning, cross-posting to governance, firefox-dev, dev-platform)</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">I've identified the following goals as critical for a responsible commit access policy:</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"></p><ul><li>Compromising a single individual's credentials must not be sufficient to land malicious code into our products.</li></ul></span></div></blockquote><div>I think this is a good long-term goal, but I don't think it's one we need to achieve now.<br></div><div>At the moment, I would settle for "only a few privileged people can single-handedly</div><div>land malicious code into our products". In support of this, I would note that what you</div><div>propose below is insufficient to achieve your stated objective, because there will</div><div>still be single person admin access to machines.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span id="m_-3670080503921479195gmail-docs-internal-guid-35bbe6a8-b500-3db2-d62d-4f874a83e6d6"><ul><li>Two-factor auth must be a requirement for all users approving or pushing a change.</li><li>The change that gets pushed must be the same change that was approved.</li><li>Broken commits must be rejected automatically as a part of the commit process.</li></ul><p></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">In order to achieve these goals, I propose that we commit to making the following changes to all Firefox product repositories:</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"></p><ul><li>Direct commit access to repositories will be strictly limited to sheriffs and a subset of release engineering.</li><ul><li>Any direct commits by these individuals will be limited to fixing bustage that automation misses and handling branch merges.</li></ul></ul></span></div></blockquote><div>I think this is a good eventual goal, but in the short term, I think it's probably useful</div><div>to keep checkin-needed floating around, especially given the somewhat iffy state</div><div>of the toolchain.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span id="m_-3670080503921479195gmail-docs-internal-guid-35bbe6a8-b500-3db2-d62d-4f874a83e6d6"><ul><li>All other changes will go through an autoland-based workflow.</li><ul><li>Developers commit to a staging repository, with scripting that connects the changeset to a Bugzilla attachment, and integrates with review flags.</li><li>Reviewers and any other approvers interact with the changeset as today (including ReviewBoard if preferred), with Bugzilla flags as the canonical source of truth.</li><li>Upon approval, the changeset will be pushed into autoland.</li></ul></ul></span></div></blockquote><div>Implicit in this is some sort of hierarchy of reviewers (tied to what was previous L3 commit?)</div><div>that says who can review a patch. Otherwise, I can just create a dummy account, r+ my own</div><div>patch, and Land Ho! IIRC Chromium does this by saying that LGTM implies autolanding</div><div>only if the reviewer could have landed the code themselves.</div><div><br></div><div>-Ekr</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span id="m_-3670080503921479195gmail-docs-internal-guid-35bbe6a8-b500-3db2-d62d-4f874a83e6d6"><ul><ul><li>If the push is successful, the change is merged to mozilla-central, and the bug updated.</li></ul></ul><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p><span class="HOEnZb"><font color="#888888"><div><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br></span></div><div><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">-- Mike</span></div></font></span></span></div>
<br>______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/<wbr>listinfo/firefox-dev</a><br>
<br></blockquote></div><br></div></div></div>