[Webkit-unassigned] [Bug 151239] This is why I love or hate the commit queue

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=151239

--- Comment #19 from Michael Catanzaro <mcatanzaro at igalia.com> ---
I'm back to only using the commit queue from the flag in Bugzilla, and only as a shortcut so I don't have to 'webkit-patch apply-from-bug' then 'webkit-patch land'.

The commit-queue seems borderline useless to me. It doesn't run tests, except on Mac (where it is useful to catch test failures), but it's extremely rare that I break Mac tests. It doesn't catch build breaks, except on Mac, but I already have to watch EWS to make sure I don't break Windows and EFL, so this is useless. If I'm making a change I think might break tests, I have to watch the test board since I know commit-queue probably won't catch it.

commit-queue would be useful if I could rely on it to catch test failures and build breakage.

We could hypothetically add a new flag, say cq++:

* cq+, to be used normally, says "commit unless it breaks a build or test on any port." Then this would be useful as it would replace the need to check EWS for failures.
* cq++ says "commit even if it breaks a non-Mac port," to be used only after cq+ has failed. When cq++ gets set, relevant port maintainers get CCed to the bug automatically.

The cost of cq++ to Apple developers would be that it takes twice as long to commit via commit-queue if the patch breaks another port, but it would make commit queue useful for the rest of us.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151231/2d96814e/attachment.html>