[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241024052139.2cf7397f@rorschach.local.home>
Date: Thu, 24 Oct 2024 05:21:39 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Guenter Roeck <linux@...ck-us.net>, Michael Ellerman
<mpe@...erman.id.au>, Christoph Hellwig <hch@...radead.org>, Kees Cook
<kees@...nel.org>, Sasha Levin <sashal@...nel.org>,
torvalds@...ux-foundation.org, ksummit@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull
requests
On Thu, 24 Oct 2024 09:01:15 +0200
Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> On Thu, Oct 24, 2024 at 5:59 AM Michael Ellerman <mpe@...erman.id.au> wrote:
> > Several thousand build tests, across pretty much every architecture.
> >
> > And a few hundred boot tests, lots virtualised, but some on real HW.
> >
> > A single character typo in an #ifdef your testing doesn't cover can
> > break the build for lots of people ...
>
> Or a missing "static" for a dummy function.
> Or a plain 64-bit division.
> Or ...
Note, my fixes code seldom adds dummy functions. I like to try to keep
them as small as possible. That's not always the case, so maybe I could
push it. But it will change my workflow quite a bit or burden Stephen
with broken branches.
I'm still not convinced it's worth it.
We are not talking about new development code. We are talking about bug
fixes for code that is in Linus's tree. The zero day bot and my tests
appear to find most issues. Bugs that happened on my fixes patches are
usually other use cases. For instance, cpu hotplug while tracing from
rtla. That's not coverage I get from linux-next.
-- Steve
Powered by blists - more mailing lists