Bug 263252 - Use shorter timeouts in release builds on Apple ports
Summary: Use shorter timeouts in release builds on Apple ports
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2023-10-17 09:14 PDT by Sam Sneddon [:gsnedders]
Modified: 2023-10-17 16:48 PDT (History)
9 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Sneddon [:gsnedders] 2023-10-17 09:14:07 PDT 
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.
Comment 1 Radar WebKit Bug Importer 2023-10-17 09:14:18 PDT 
<rdar://problem/117078331>