renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin

[Mark Brown]

On Wed, Dec 14, 2022 at 03:16:33PM +0100, Guillaume Tucker wrote:

> Mark, how did you get the list of recipients?

> There's a command for this btw, which was used when the reports
> were automatically sent to the recipients before we reverted to
> manual filtering to reduce the noise:

My standard thing is to look at who touched the commit, possibly also
adding seemingly relevant maintainers depending on how good the list
from the commit was (IIRC in this case the commit went entirely through
ChromeOS people so I added relevant DRM submaintainers which turned out
to be a surprisingly large number of people), and relevant lists.

> As you can see, Geert is not listed there.

I didn't send the report to Geert as far as I can see, I imagine he saw
it as a result of it going to one of the lists and noticed the mention
of Renesas as the tree, possibly he's got some filter set up to find
things that mention it.  The recipient list I have is:

| To: kernelci-results at groups.io, bot at kernelci.org, Brian Norris
|         <briannorris at chromium.org>, Sean Paul <seanpaul at chromium.org>, Douglas
|         Anderson <dianders at chromium.org>
| Cc: gtucker at collabora.com, dri-devel at lists.freedesktop.org,
|         linux-arm-kernel at lists.infradead.org, Andrzej Hajda
|         <andrzej.hajda at intel.com>, Neil Armstrong <neil.armstrong at linaro.org>,
|         Robert Foss <robert.foss at linaro.org>, Laurent Pinchart
|         <Laurent.pinchart at ideasonboard.com>, Jonas Karlman <jonas at kwiboo.se>,
|         Jernej Skrabec <jernej.skrabec at gmail.com>

which doesn't mention him at all.

> >> Yes it would be good to have 2nd order regressions based on a
> >> reference branch (e.g. mainline in this case) in KernelCI but
> > 
> > Sorry, I don't know what is a "2nd order regression".
> 
> Regressions are basically a delta between results in a given
> revision and the previous one on the same branch (new failures).
> What I call "2nd order" regressions are a delta of these
> regressions compared to another reference branch.  For example,
> regressions that are in a particular tree and aren't also in
> mainline such as the one at hand which isn't specific to renesas.

Like I said in the other mail there is something going on which means
that a *very* lerge proportion of our bisection results are found in the
Renesas tree.

> >> that's for next year.  Regardless, it found a commit and the
> >> bisection looks legit.

> > Good. So please report it to the relevant parties.

That's what I did...

> > While bisecting, as soon as you happen to arrive at a commit
> > that is already upstream...

> > 'ata-6.0-rc2' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata
> >     > git bisect bad 044610f8e4155ec0374f7c8307b725b7d01d750c
> > (which happens here  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^)

> > ... there is no point in "blaming" any of the bisection points before.

I'm not sure I understand the logic here?  The goal with a bisection is
to identify which commit caused an issue to aid in resolving whatever
the problem is.  It doesn't really matter if this happens before or
after the commit lands in Linus' tree.  I do agree that the tree
mentioned becomes a bit misleading though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20221214/cbbb4bc1/attachment.sig>