From: Tomi Sarvela <tomi.p.sarvela@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org, shashidhar.hiremath@intel.com
Subject: Re: [PATCH v8 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6
Date: Tue, 16 Feb 2016 17:45:52 +0200 [thread overview]
Message-ID: <2189084.EpKU0XL0QA@fractal> (raw)
In-Reply-To: <20160216152843.GJ32705@phenom.ffwll.local>
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2016-02-16 15:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1454531039.12879.4.camel@intel.com>
2016-02-05 18:43 ` [PATCH v8 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6 Sagar Arun Kamble
2016-02-05 21:38 ` Imre Deak
2016-02-08 9:19 ` Jani Nikula
2016-02-08 14:18 ` Imre Deak
2016-02-08 15:08 ` Jani Nikula
2016-02-15 17:07 ` Daniel Vetter
2016-02-16 7:52 ` Tomi Sarvela
2016-02-16 15:28 ` Daniel Vetter
2016-02-16 15:45 ` Tomi Sarvela [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2189084.EpKU0XL0QA@fractal \
--to=tomi.p.sarvela@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=shashidhar.hiremath@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.