<tardyp>
I wasn't able to reproduce locally, but in the CI, we get tons of deprecation warnings from boto/mptp
<p12tic>
lgtm
<tardyp>
p12tic: there there is 6286 which is a bit more tricky. I don't like too much the need to put clock.advance everywhere
<tardyp>
if you have some thoughts about the problem
<p12tic>
if we depend on time there's not much other choice
<tardyp>
we don't really depend on time, its more of a trick to wait for all the events to arrive
<p12tic>
yes, but it the trick depends on time
<p12tic>
other option would have an internal method for tests only
<tardyp>
because the buildrequest distributor kicks in at first event, but for a buildset we have several buildrequest that will arrive
<tardyp>
I was thinking about disabling the delay in tests indeed
<tardyp>
but then you don't really test the real thing..
<p12tic>
yep
<p12tic>
I don't mind clock.advance too much to be honest. It's not too large mental overhead
<p12tic>
Having facilities that make testing less verbose adds more mental overhead because now one needs to understand these facilities as well
<tardyp>
p12tic: what is hard for this is to find were to advance the clock because you need to put it everytime a buildrequest is created or unclaimed
<tardyp>
this was a headacke in the latent worker tests