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

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>