263252 2023-10-17 09:14:07 -0700 Use shorter timeouts in release builds on Apple ports 2023-10-17 16:48:46 -0700 1 1 1 Unclassified WebKit Tools / Tests WebKit Nightly Build Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=173368 https://bugs.webkit.org/show_bug.cgi?id=263260 InRadar P2 Normal --- 1 gsnedders webkit-unassigned ap ben_schwartz darbinyan jbedard jenner Morningstar rackler ryanhaddad webkit-bug-importer oldest_to_newest 1985579 0 gsnedders 2023-10-17 09:14:07 -0700 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. 1985580 1 webkit-bug-importer 2023-10-17 09:14:18 -0700 <rdar://problem/117078331>