<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 10, 2017 at 7:23 PM, smaug via governance <span dir="ltr"><<a href="mailto:governance@lists.mozilla.org" target="_blank">governance@lists.mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 03/10/2017 12:59 AM, Bobby Holley wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
At a high level, I think the goals here are good.<br>
<br>
However, the tooling here needs to be top-notch for this to work, and the<br>
standard approach of flipping on an MVP and dealing with the rest in<br>
followup bugs isn't going to be acceptable for something so critical to our<br>
productivity as landing code. The only reason more developers aren't<br>
complaining about the MozReview+autoland workflow right now is that it's<br>
optional.<br>
<br>
The busiest and most-productive developers (ehsan, bz, dbaron, etc) tend<br>
not to pay attention to new workflows because they have too much else on<br>
their plate. The onus needs to be on the team deploying this to have the<br>
highest-volume committers using the new system happily and voluntarily<br>
before it becomes mandatory. That probably means that the team should not<br>
have any deadline-oriented incentives to ship it before it's ready.<br>
<br></span><span class="">
Also, getting rid of "r+ with comments" is a non-starter.<br>
</span></blockquote>
<br>
FWIW, with my reviewer hat on, I think that is not true, _assuming_ there is a reliable interdiff for patches.<br>
And not only MozReview patches but for all the patches. (and MozReview interdiff isn't reliable, it has dataloss issues so it<br>
doesn't really count there.).<br>
I'd be ok to do a quick r+ if interdiff was working well.<br></blockquote><div><br></div><div>Without taking a position on the broader proposal, I agree with this.</div><div><br></div><div>We have been using Phabricator for our reviews in NSS and its interdiffs work pretty well</div><div>(modulo rebases, which are not so great), and it's very easy to handle LGTM with</div><div>nits and verify the nits.</div><div><br></div><div>-Ekr</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
-Olli<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
bholley<span class=""><br>
<br>
<br>
On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor <<a href="mailto:mconnor@mozilla.com" target="_blank">mconnor@mozilla.com</a>> wrote:<br>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
(please direct followups to dev-planning, cross-posting to governance,<br>
firefox-dev, dev-platform)<br>
<br>
<br>
Nearly 19 years after the creation of the Mozilla Project, commit access<br>
remains essentially the same as it has always been. We've evolved the<br>
vouching process a number of times, CVS has long since been replaced by<br>
Mercurial & others, and we've taken some positive steps in terms of<br>
securing the commit process. And yet we've never touched the core idea of<br>
granting developers direct commit access to our most important<br>
repositories. After a large number of discussions since taking ownership<br>
over commit policy, I believe it is time for Mozilla to change that<br>
practice.<br>
<br>
Before I get into the meat of the current proposal, I would like to outline<br>
a set of key goals for any change we make. These goals have been informed<br>
by a set of stakeholders from across the project including the engineering,<br>
security, release and QA teams. It's inevitable that any significant<br>
change will disrupt longstanding workflows. As a result, it is critical<br>
that we are all aligned on the goals of the change.<br>
<br>
<br>
I've identified the following goals as critical for a responsible commit<br>
access policy:<br>
<br>
<br></span>
- Compromising a single individual's credentials must not be sufficient<span class=""><br>
to land malicious code into our products.<br></span>
- Two-factor auth must be a requirement for all users approving or<br>
pushing a change.<br>
- The change that gets pushed must be the same change that was approved.<br>
- Broken commits must be rejected automatically as a part of the commit<span class=""><br>
process.<br>
<br>
<br>
In order to achieve these goals, I propose that we commit to making the<br>
following changes to all Firefox product repositories:<br>
<br>
<br></span>
- Direct commit access to repositories will be strictly limited to<span class=""><br>
sheriffs and a subset of release engineering.<br></span>
- Any direct commits by these individuals will be limited to fixing<span class=""><br>
bustage that automation misses and handling branch merges.<br></span>
- All other changes will go through an autoland-based workflow.<br>
- Developers commit to a staging repository, with scripting that<span class=""><br>
connects the changeset to a Bugzilla attachment, and integrates<br>
with review<br>
flags.<br></span>
- Reviewers and any other approvers interact with the changeset as<span class=""><br>
today (including ReviewBoard if preferred), with Bugzilla flags as<br>
the<br>
canonical source of truth.<br></span>
- Upon approval, the changeset will be pushed into autoland.<br>
- If the push is successful, the change is merged to mozilla-central,<span class=""><br>
and the bug updated.<br>
<br>
I know this is a major change in practice from how we currently operate,<br>
and my ask is that we work together to understand the impact and concerns.<br>
If you find yourself disagreeing with the goals, let's have that discussion<br>
instead of arguing about the solution. If you agree with the goals, but<br>
not the solution, I'd love to hear alternative ideas for how we can achieve<br>
the outcomes outlined above.<br>
<br>
-- Mike<br></span><span class="">
______________________________<wbr>_________________<br>
dev-planning mailing list<br>
<a href="mailto:dev-planning@lists.mozilla.org" target="_blank">dev-planning@lists.mozilla.org</a><br>
<a href="https://lists.mozilla.org/listinfo/dev-planning" rel="noreferrer" target="_blank">https://lists.mozilla.org/list<wbr>info/dev-planning</a><br>
<br>
</span></blockquote></blockquote>
<br>
______________________________<wbr>_________________<br>
governance mailing list<br>
<a href="mailto:governance@lists.mozilla.org" target="_blank">governance@lists.mozilla.org</a><br>
<a href="https://lists.mozilla.org/listinfo/governance" rel="noreferrer" target="_blank">https://lists.mozilla.org/list<wbr>info/governance</a><br>
</blockquote></div><br></div></div>