On Mon, 10 Feb 2020, Arkadiusz Hiler <arkadiusz.hi...@intel.com> wrote: > As of the 3 days worth of queued shards: > > I agree that this is unacceptable, but we can do only so much from the > CI/infra side. The time has been creeping up steadily over the last year > or so and the machines are not getting any faster.
I am *not* trying to say that it's all your fault and you need to provide all results faster for the ever-increasing firehose of incoming patches. I'd like to pose the question, what would all this look like if we made it a hard requirement that we need a go/no-go decision on every patch series within 24 hours? I emphasize that I don't mean full results in 24 hours. Given all the other constraints, how could we provide as much useful information as possible within 24 hours to make a decision? In another thread I said, we've shifted a bit from review being the bottle neck to shard runs being the bottle neck. It's still much more likely that a patch will change due to review feedback instead of shard run results. Half a dozen rounds of review ping pong directly leads to half a dozen rounds of mostly unnecessary testing. I would not outright dismiss only running full igt on reviewed/acked patches. Additionally, there are smaller optimizations to be made (obviously all depending on developer bandwidth to implement this stuff), such as identifying patches that don't change the resulting binary (comment/documentation/whitespace changes), and only running build testing on them. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
