Re: stable-rc/linux-4.14.y bisection: baseline.login on meson8b-odroidc1

["Ricardo Cañuelo" <ricardo.canuelo@collabora.com>]

Hey Thorsten,

Thanks for bringing this up, I think what you mentioned is
interesting in a more general way, so let me use this email to
share my impressions about the approach to reporting regressions
and the role of the reporter.

On 4/5/23 11:06, Linux regression tracking (Thorsten Leemhuis) wrote:
> Have you tried if reverting the change on top of the latest 4.14.y
> kernel works and looks safe (e.g. doesn't cause a regression on its own)?

No, I haven't. To be honest, my current approach when I'm
reporting regressions is to act merely as a reporter, making sure
the regression summaries reach the right people and providing as
much info as possible with the data we gather from the test runs
in KernelCI.

Sometimes I stop for some more time in a particular regression
and I test it / investigate it more thoroughly to find the exact
root cause and try to fix it, but I consider that to be beyond
the role of a reporter. At that point I'm basically trying to
find a fix, and that's much more time consuming.

> I also briefly looked into "git log v4.14..v4.19 --
> arch/arm/boot/dts/meson.dtsi" and noticed commit 291f45dd6da ("ARM: dts:
> meson: fixing USB support on Meson6, Meson8 and Meson8b") [v4.15-rc1]
> that mentions a fix for the Odroid-C1+ board -- which afaics wasn't
> backported to 4.14.y. Is that maybe why this happens on 4.14.y and not
> on 4.19.y? Note though: It's just a wild guess from the peanut gallery,
> as this is not my area of expertise!

Maybe, that's the kind of thing that someone who's familiar with
the code (author / maintainers) can quickly evaluate. What you
said about that not being your area of expertise is key, IMO. I
don't think it's reasonable to expect a single person to
investigate every possible type of regression. Investigating a
bug could take me 5 minutes if it's something trivial or a few
days if it's not and I'm not familiar with it, while the patch
author/s could probably have it assessed and fixed in
minutes. That's why I think that providing the regression info to
the right people is a better use of the reporter's time.

There are many of us now in the community that are working
towards building a common effort for regression reporting, so
maybe we should take some time to define the roles involved and
gather ideas about how to approach certain types of problems.

Thanks,
Ricardo