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@xxxxxxxxx, bot@xxxxxxxxxxxx, Brian Norris | <briannorris@xxxxxxxxxxxx>, Sean Paul <seanpaul@xxxxxxxxxxxx>, Douglas | Anderson <dianders@xxxxxxxxxxxx> | Cc: gtucker@xxxxxxxxxxxxx, dri-devel@xxxxxxxxxxxxxxxxxxxxx, | linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, Andrzej Hajda | <andrzej.hajda@xxxxxxxxx>, Neil Armstrong <neil.armstrong@xxxxxxxxxx>, | Robert Foss <robert.foss@xxxxxxxxxx>, Laurent Pinchart | <Laurent.pinchart@xxxxxxxxxxxxxxxx>, Jonas Karlman <jonas@xxxxxxxxx>, | Jernej Skrabec <jernej.skrabec@xxxxxxxxx> 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.
Attachment:
signature.asc
Description: PGP signature
