The solution I'd recommend is to make the JavaScriptCore and/or
WebKit2 bots faster. If those bots are able to complete their
processing before the commit-queue, then they'll stop the patch from
being committed by marking the patch commit-queue-.
Adam
On Thu, Jan 10, 2013 at 9:22 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi all,
As you might all know, the commit-queue uses chromium linux port.
Consequently, any JavaScriptCore and WebKit2 specific changes (and any
non-Chromium port specific changes) are never tested. Commit-queue doesn't
even detect whether it builds or not.
This is a source of confusion because many (new) contributors appear to
mistakenly think that commit-queue ensures that the patch builds passes
tests on all platforms yet commit-queue doesn't wait until EWS bots process
a patch before landing it. As a result, I've seen quite a few people landing
patches that break JSC/WK2 via commit-queue.
My initial proposal was to make commit-queue wait until EWS bots catch up
when landing a port specific or JSC/WK2 specific changes. However, Adam
thinks that's a bad idea (webkit.org/b/74776) because EWS bots are only
advisory and waiting for EWS bots slows things down.
Is this a problem worth finding a solution? If so, do you have any
suggestions?
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
