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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wj4aSJsVA6weV7u9KD1yA74JZq3dYZKbUtxp=3o_esnVA@mail.gmail.com>
Date: Wed, 23 Oct 2024 11:06:59 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: paulmck@...nel.org
Cc: Christoph Hellwig <hch@...radead.org>, Sasha Levin <sashal@...nel.org>, Kees Cook <kees@...nel.org>, 
	ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull requests

On Wed, 23 Oct 2024 at 10:47, Paul E. McKenney <paulmck@...nel.org> wrote:
>
> > 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.

Yes. I definitely care about failures in linux-next, but I often don't
_know_ about them unless I'm told.

The linux-next automation sends notifications to the owners of the
trees, but not to me.

And that is as it should be - I don't want to be spammed by everything
that is found in linux-next.

So failures should normally be fixed by the owners of the trees when
they get detected, and those trees should not even make it as pull
requests until the problem has been resolved.

After all, that's kind of the point of linux-next - finding problems
*before* they become pull requests.

But that does mean that if some failure has been detected in
linux-next, and the maintainer has *not* corrected it, I don't even
know about it. And most maintainers are very good about this, and
point to things like the resolution reports (which are not actual
problems, just heads-up).

So automation that says "this tree does not actually work" would very
much be appreciated. I'd prefer them to be the same kind of "before
the pull request has even been sent" situation, of course, but if
problems _remain_ in linux-next, and pr-bot sees the pull request, I'd
actually like automation that says "Oh, this tree has these issues:
..."

IOW, I very much do care. linux-next has improved our build test
coverage and is a big deal. The more "problem coverage" it has, even
outside of just build issues, the better.

And yes, I know some people do functional testing on linux-next
already. The message at the maintainer summit was a bit mixed with
some people saying linux-next tends to work even for that, others
saying it's often too broken to be useful.

              Linus