Re: [Intel-gfx] [PATCH] drm/i915/mst: fix pipe and vblank enable

[Jani Nikula <jani.nikula@intel.com>]

On Mon, 10 Feb 2020, Arkadiusz Hiler <arkadiusz.hiler@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