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 <[email protected]> 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 > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
