[PATCH v3 11/15] ASoC: Intel: avs: Machine board registration

[Mark Brown]

On Sun, May 29, 2022 at 07:48:07AM +0200, Uwe Kleine-König wrote:
> On Thu, May 26, 2022 at 06:44:38PM +0100, Mark Brown wrote:

> > FWIW given how hard the 0-day reports have become to read I'd not rely
> > on people paying attention to things that are clearly pure build
> > coverage based off a 0-day report alone.

> I'm unsure if I understand your sentiment correctly. Are you saying it
> doesn't matter if a patch breaks the build on some arch using a
> randconfig?

It matters, but in practice something that is only reported by an
automated tool with a hard to read report against a a randconfig
on an obscure platform that you need to go find a toolchain for
is a lot more likely to get buried than something that doesn't
have those properties.  Similarly if a tool is sending a lot of
reports with those properties it's a lot easier for even reports
in more important issues from that tool to get dropped on the
floor.

> My position is: The commit under discussion (i.e. beed983621fb ("ASoC:
> Intel: avs: Machine board registration")) breaks an allmodconfig build
> on all platforms where __fls doesn't return a long int (i.e. arc, m68k,
> and sparc). This actively hurts people who do build tests using
> allmodconfig (or allyesconfig) for their patch series (e.g. me).

> I agree that some reports by the 0-day bot are hard to parse. But still,
> if there is a build problem someone should look into that. If you (with
> your maintainer hat on) don't have the resource to do that, that's IMHO
> fine. But I'd wish you'd push back on the patch submitter in that case
> and don't apply the patch until the problem is resolved. If this is a
> corner case randconfig issue, applying might be fine despite the build
> error but breaking allmodconfig on 3 archs is bad.

My general approach here is that I'm expecting the reports from 0
day to be enough so I don't explicitly push back, but I don't
generally apply anything that looks like it has a live issue.  In
this case it looks like what happened was that 0-day only
reported against v2 and not v3 so it wasn't apparent to me that
the report hadn't been addressed in the new version, there
weren't any reports against v3 that I can see.

The other thing here is that if something did get missed and ends
up getting applied it really helps to get an explicit report that
there's a problem in -next, clearly something got missed and it's
much easier to get something dropped just after it gets applied.
TBH I hadn't realised from the followup that this was an
all*config issue, my best guess was that it was a randconfig
thing thatg got missed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20220530/d4c3a78e/attachment.sig>