[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZxoSZQSw0z6AdgaU@infradead.org>
Date: Thu, 24 Oct 2024 02:24:53 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
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, Oct 24, 2024 at 05:21:39AM -0400, Steven Rostedt wrote:
> 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.
Seriously, just add your damn fixes tree to linux-next. If your fixes
are as perfect as you claim that one time setup is all you need to do,
and you have less work than you spent arguing on this thread already.
If it catches bugs eventually you will need to do more work, but save
others from deadling with your regression. There is no downside for
you.
Powered by blists - more mailing lists