995060 - Increase maxtime for browser-chrome-1

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Phil Ringnalda (:philor)]

Attachment: 9000?!

Chunk-by-dir moved a crapload of the slow into bc1, without moving the maxtime allocation around, so we're (along with the other reasons every tree is closed) closed because it's permared. This (and the bc2 maxtime) doesn't call for a lot of thought, since we plan to rip the devtools tests out, and thus take away all the time, tomorrow if we're lucky.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 8405149 [details] [diff] [review]
9000?!

https://hg.mozilla.org/build/buildbot-configs/rev/5ba1d8ce4512   (default)
https://hg.mozilla.org/build/buildbot-configs/rev/84265f3408a8   (production)

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

In production.

Comment 3

[Phil Ringnalda (:philor)]

Turned out to only sometimes be enough, I should have gone with my gut and used 12000.

Comment 4

[Phil Ringnalda (:philor)]

12000: https://hg.mozilla.org/build/buildbot-configs/rev/3a6fc4607252

Comment 5

[Carsten Book [:Tomcat]]

note (since this bug is mentioned in the tree closure message) the tree status info on https://sheriffs.etherpad.mozilla.org/sheriffing-notes? was updated with steps we need to do to reopen the trees

Comment 6

[Ed Morley [:emorley]]

Retriggers in progress to check we're still green.

Comment 7

[Ed Morley [:emorley]]

Note that Linux debug browser-chrome-1 will take up to 3 hours to complete, so we may be waiting some time.

Comment 8

[Ed Morley [:emorley]]

Green, trees reopened.
Closing bug since the attached patch landed and was reconfiged.