Author pdgoins
Recipients db3l, paul.moore, pdgoins, steve.dower, tim.golden, vstinner, zach.ware
Date 2018-05-16.05:37:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1526449044.68.0.682650639539.issue33355@psf.upfronthosting.co.za>
In-reply-to
Content
If we consider this to be the new normal...  What about increasing the timeout to accomodate?  From what I could gather, builds were running around 13 minutes or so before the changes, so the timeout wasn't much above actual exec time to begin with.  Maybe bump the timeout up to 20, maybe even 30 minutes?  (Granted, I don't know the intent of the timeout: whether it was intended to capture sudden performance delays like this in case of adverse code changes, or whether 15 minutes simply "sounded good" and thus was set.)

I know that for my own projects I would be reluctant to suggest the above; it seems better to dig in and understand why there was such a jump in exec time on test_io.  But without having access to the build agents nor having an environment handy which reproduces the issue, this is the best suggestion I can come up with to move this towards resolution.
History
Date User Action Args
2018-05-16 05:37:24pdgoinssetrecipients: + pdgoins, paul.moore, db3l, vstinner, tim.golden, zach.ware, steve.dower
2018-05-16 05:37:24pdgoinssetmessageid: <1526449044.68.0.682650639539.issue33355@psf.upfronthosting.co.za>
2018-05-16 05:37:24pdgoinslinkissue33355 messages
2018-05-16 05:37:24pdgoinscreate