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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]

On Tue, Oct 22, 2024 at 07:51:03AM -0400, James Bottomley wrote:
> On Tue, 2024-10-22 at 04:12 -0400, Steven Rostedt wrote:
> > Christoph Hellwig <hch@infradead.org> wrote:

> > But when I find a bug that's in Linus's tree, I put the fix on top of
> > "urgent", run it through my test suite (takes 8 hours or so), then
> > send a pull request to Linus. My "urgent" branch doesn't go into
> > linux-next as it doesn't have changes that should affect others work,
> > which is what I think linux-next is mostly for.

> That's not necessarily a safe assumption.  The reason we put scsi-fixes
> into -next is precisely to pick up if this happens.  I admit it happens
> very rarely because of the compact and local nature of the fixes, but
> the signal rate isn't zero.

Yeah, just yesterday there was a cross architecture build break
introduced by a fix in the selftests.

The whole reason pending-fixes exists is that we had a disruptive
problem with fixes that hadn't been given enough coverage at some point,
IIRC in the case that immediately inspired it was that there was a
dependency on changes that were only in -next that hadn't been noticed
which is why we've now got the fixes tested independently of any new
development.  

> >  I also find known bugs in Linus's tree to be high priority to be
> > fixed (I stop what I'm doing to get the fix out ASAP).

> > Now, if there was better testing from linux-next, maybe it would be
> > worth the time to push my urgent branch there for a bit. But so far I
> > haven't seen the benefit of doing that.

> It does at least get 0day running over it, although that can also be
> configured for your branches separately as well.  It's also not unwise
> to have some pause time before fixing and sending ... the fix you first
> thought of isn't always the best one (or even sometimes an actual fix).

I'm also covering it in my CI and do occasionally find issues there, as
does KernelCI.  There's probably others I'm less aware of.  TBH half the
reason I cover it is that it also cuts down the number of bisect steps
for -next a little.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]