https://chromium-cq-status.appspot.com/recent#issue=2485783002,patchset=120001,codereview_hostname=codereview.chromium.org is the most recent patch to land and sat at "Patch ready to commit" for a really long time.

Is this fallout and/or a bug caused by the webkit master restart?

I'm looking into this now, I don't expect that this is related to the master restart though (but maybe)

It looks like the CQ is busy trying to commit http://chromiumcodereview.appspot.com/2496663002, which I'm not actually able to get to successfully load at the moment..

Ah, https://codereview.chromium.org/2496663002 loads for me. This patch is ginormous, which explains it.

This change could be landed manually. Can we take it out of the CQ?

I have taken the patch out of the CQ by unchecking the commit box.

Yeah this should be landed manually I think.... It looks like there's a larger bug here though, which is that huge patches can take the CQ out of commission. Fortunately, I think this is a complete non-issue once chromium switches to gerrit. I think this is an artifact of the rietveld patching system.

For CQ folks: it appears that CQ calls `git add` or `git rm` once for every file in the patch. This is apparently inefficient enough (?) that I suspect that it takes the CQ > cq_restart_cycle time to actually commit the patch. Thus the CQ spends all its time attempting to commit this, then it gets restarted, and the whole thing goes again.

iannucci@ yeah, that sounds about right. Indeed, once I make Gerrit operation for Chromium, all the big patches should land just fine through it and with lower latency.

In current Rietveld CQ, there isn't that much we can do without major re-architecturing which will take longer than getting Gerrit operation anyway.

Use gerrit for all patches :)