Re: linus-next: improving functional testing for to-be-merged pull requests

[Guenter Roeck]

On 10/23/24 10:47, Paul E. McKenney wrote:
> On Tue, Oct 22, 2024 at 10:50:04PM -0700, Christoph Hellwig wrote:
> > On Tue, Oct 22, 2024 at 05:37:38AM -0400, Sasha Levin wrote:
> > > We could add a report for the above, but:
> > >
> > > 1. Linus consistently pulls patches that haven't seen the light of day.
> > > 2. Linus explicitly objected to making a linux-next a must have.
> > >
> > > So unless these results would be actually used, what's the point in
> > > writing all of that?
> >
> > Yes, without Linus caring we're not going to get our process worked out.
> > Not sure how a tree that probably won't have much better latency than
> > linux-next is going to fix that, though.
>
> If I recall correctly, one thing Linus asked us to do earlier this year
> (ARM Summit) is to CC him on -next failures.  I have been failing to do
> this, so I will post myself a note or something to remind me.
>
> After all, if Linus doesn't know of a problem with a set of commits,
> how does he know not to pull it?

As of right now:

Build results:
	total: 158 pass: 144 fail: 14
Failed builds:
	arm:axm55xx_defconfig
	csky:defconfig
	i386:allyesconfig
	i386:allmodconfig
	microblaze:defconfig
	mips:allmodconfig
	mips:mtx1_defconfig
	mips:db1xxx_defconfig
	openrisc:allmodconfig
	parisc:allmodconfig
	parisc64:generic-64bit_defconfig
	sh:defconfig
	sh:shx3_defconfig
	xtensa:allmodconfig
Qemu test results:
	total: 556 pass: 528 fail: 28
Unit test results:
	pass: 463943 fail: 0

And that is a good day. Sometimes dozens of builds and hundreds
of boot tests fail. Analyzing those failures would be a full-time job.
Who do you expect would or should do that ?

Guenter