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.