Closed SethTisue closed 9 years ago
LGTM
I think the real solution is to limit concurrency. There should only be one release job running at a time. No need to increase timeout for all jobs. We want to detect when they start taking longer. Note that the build passed without this change (merging doesn't actually deploy the change).
(the build took 160 minutes — it only passed because I also manually increased the timeout in the Jenkins UI)
good call! :rabbit:
also, it's possible that the increased time in this case had to do with concurrency, but it might also just be that the M2 compiler is slow. Jon Pretty is reporting "23% slower" than 2.11
yep, we should increase, but only just enough so that we discover further slow downs -- Lukas & Jason are going to focus on optimizing the optimizer, so I don't expect this to be a problem :)
In any case, we shouldn't increase the timeout for 2.11.x
agree. see new ticket
because an attempt at a 2.12.0-M2 release build failed today by running afoul of the old timeout
review/merge by @adriaanm