<div dir="ltr">Following up in this. We're not the first people to have autoland, so is there some reason<div>not to simply copy what others do here. Specifically, here's the Chromium commitbot</div><div>behavior: <a href="https://www.chromium.org/developers/testing/commit-queue">https://www.chromium.org/developers/testing/commit-queue</a></div><div><br></div><div><h3>Current process for the user</h3>
<div>
<ol><li>Upload a review to rietveld where it gets reviewed and LGTM'ed.</li>
<li>One of:</li>
<ol><li>Check (select) the 'Commit' checkbox on a Rietveld issue, on the
 particular patchset that has been approved. Checking the checkbox is 
the only action required and there will be no immediate feedback in the 
form of messages, etc, to notify you that something has happened.</li>
<ul><li>Only the issue owner, someone at @<a href="http://chromium.org">chromium.org</a> or @<a href="http://google.com">google.com</a> can check the box.</li>
<li>Yes, <b>non-Chromium committers are allowed </b>to use the commit queue but cannot LGTM a change.</li></ul>
<li>At the command line, type <code>git cl set_commit</code></li>
<li>Have a reviewer use 'Quick LGTM & CQ'.</li>
</ol>
<li>Wait an hour. The current list of patches to be queued can be found at <a href="https://codereview.chromium.org/search?closed=3&commit=2">Commit Queue Patches</a>, while CQ progress can be tracked at <a href="https://chromium-cq-status.appspot.com/">Commit Queue Progress</a>. The commit queue will wait automatically for the tree to reopen.</li>
<li>Wait for an email from <a href="mailto:commit-bot@chromium.org">commit-bot@chromium.org</a> with success or failure.</li></ol></div></div><div>-Ekr</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 23, 2016 at 8:07 AM, Eric Rescorla <span dir="ltr"><<a href="mailto:ekr@rtfm.com" target="_blank">ekr@rtfm.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">IMO the right place for this checkbox is in the review request, which puts the<div>control in the right place: the patch author.<br><div><br></div><div>-Ekr</div><div><div class="h5"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 21, 2016 at 7:00 PM, Dave Townsend <span dir="ltr"><<a href="mailto:dtownsend@mozilla.com" target="_blank">dtownsend@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Should we just add a "and land it" checkbox to the review page, maybe<br>
disabled if there are still open issues?<br>
<div><div><br>
On Thu, Jan 21, 2016 at 6:35 PM, Gregory Szorc <<a href="mailto:gps@mozilla.com" target="_blank">gps@mozilla.com</a>> wrote:<br>
> If you have level 3 source code access (can push to central, inbound,<br>
> fx-team) and have pushed to MozReview via SSH, as of a few weeks ago you can<br>
> now land commits from the "Automation" drop down menu on MozReview. (Before<br>
> only the review request author could trigger autoland.)<br>
><br>
> This means that anyone [with permissions] can land commits with a few mouse<br>
> clicks! It will even rewrite commit messages with "r=" annotations with the<br>
> review state in MozReview. So if someone does a drive-by review, you don't<br>
> have to update the commit message to reflect that reviewer. Neato!<br>
><br>
> I've gotten into the habit of just landing things if I r+ them and I think<br>
> they are ready to land. This has startled a few people because it is a major<br>
> role reversal of how we've done things for years. (Typically we require the<br>
> patch submitter to do the landing.) But I think reviewer-initiated landing<br>
> is a better approach: code review is a gate keeping function so code<br>
> reviewers should control what goes through the gate (as opposed to patch<br>
> authors [with push access] letting themselves through or sheriffs providing<br>
> a support role for people without push access). If nothing else, having the<br>
> reviewer land things saves time: the ready-to-land commit isn't exposed to<br>
> bit rot and automation results are available sooner.<br>
><br>
> One downside to autoland is that the rebase will happen remotely and your<br>
> local commits may linger forever. But both Mercurial and Git are smart<br>
> enough to delete the commits when they turn into no-ops on rebase. We also<br>
> have bug 1237778 open for autoland to produce obsolscence markers so<br>
> Mercurial will hide the original changesets when you pull down the rebased<br>
> versions. There is also potential for some Mercurial or Git command magic to<br>
> reconcile the state of MozReview with your local repo and delete local<br>
> commits that have been landed. This is a bit annoying. But after having it<br>
> happen to me a few times, I think this is a minor annoyance compared to the<br>
> overhead of pulling, rebasing, rewriting commit messages, and pushing<br>
> locally, possibly hours or days after review was granted.<br>
><br>
> I encourage my fellow reviewers to join me and "just autoland it" when<br>
> granting review on MozReview.<br>
><br>
> gps<br>
><br>
</div></div>> _______________________________________________<br>
> firefox-dev mailing list<br>
> <a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
><br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</blockquote></div><br></div></div></div></div></div></div>
</blockquote></div><br></div>