[Intel-gfx] [PATCH v8 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

[Tomi Sarvela]

On Tuesday 16 February 2016 16:28:43 Daniel Vetter wrote:
> On Tue, Feb 16, 2016 at 09:52:49AM +0200, Tomi Sarvela wrote:
> > What kind of status dashboard would be good? As mentioned, CI itself was
> > all good and well, and status board would reflect that.
> 
> Well status board should also include status of patchwork jobs, and if
> they're down why exactly ("drm-intel-nightly on fire"). So yeah I don't
> expect that the status board will show "CI is down" at all ever (or at
> least I hope), but communicating why patches aren't being tested would be
> good. Later on we could also put up some kind of queue, so that people
> know how long it'll take when there's a backlog for CI to get around to
> their patch.

The problem is that the patches are not taken from one queue: there is (in 
priority order) CI_DIF, CI_DINF, CI_DRM, CI_Patchwork and soon-to-be 
CI_Private. Patchwork and Private work by advancing from old patchseries to 
new, others just take newest and roll with it (no matter how many new 
commits). In short, we're doing one thing at a time, statelessly.

So, what can be done:

Patchwork/Private queue can be scanned for the next <n> patches, but the order 
changes if there's new revision, and the estimated time changes if there's 
drm-intel-nightly pushed (which is higher in priority). Can't know either in 
advance. Might be still useful to get information that next two things to be 
tested is "probably not you".

Jenkins status can be queried, but it's usually "Yes, I'm working". More 
specifically it can return easily CI_DRM or CI_Patchwork job it's waiting to 
finish, but that isn't terribly useful.

Jenkins jobs can be queried easily: interesting might be status of 
CI_Patchwork_check (disabled if there's hot in CI_DRM side).

Better estimates would all depend on getting rid of the prio-queues. That 
might be possible, but current order has worked well so far.

Tomi