Bug 263252
| Summary: | Use shorter timeouts in release builds on Apple ports | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Sam Sneddon [:gsnedders] <gsnedders> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, ben_schwartz, darbinyan, jbedard, jenner, Morningstar, rackler, ryanhaddad, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=173368 https://bugs.webkit.org/show_bug.cgi?id=263260 |
||
Sam Sneddon [:gsnedders]
Currently we almost always use the same (30s) timeout, including across release and debug. (c.f. https://github.com/WebKit/WebKit/blob/22320bd353b3ad1608a61825af92b285f3ee77ab/Tools/Scripts/webkitpy/port/base.py#L186-L187 and https://github.com/WebKit/WebKit/blob/22320bd353b3ad1608a61825af92b285f3ee77ab/Tools/Scripts/webkitpy/port/apple.py#L90-L93)
By comparison, glib differs timeouts based on release/debug (15s/30s): https://github.com/WebKit/WebKit/blob/22320bd353b3ad1608a61825af92b285f3ee77ab/Tools/Scripts/webkitpy/port/glib.py#L57-L65
We can almost certainly cut down the timeout in release, and given glib already does this, it probably isn't actually too risky.
Bug 173368, which increased the glib (well, then GTK) timeouts is potentially of interest here: it increased the timeouts from 6s/12s (release/debug), apparently inherited from the old Chromium port(!), because those timeouts turned out to be too short.
I'm also going to file a (somewhat related) issue about how we currently configure testharness.js timeouts, as these are almost certainly too long.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/117078331>