[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0cf2898d-da29-470d-9b26-ff5f85ccd437@leemhuis.info>
Date: Wed, 23 Oct 2024 12:18:28 +0200
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Vlastimil Babka <vbabka@...e.cz>, Steven Rostedt <rostedt@...dmis.org>,
Christoph Hellwig <hch@...radead.org>
Cc: 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 23.10.24 11:32, Vlastimil Babka wrote:
> On 10/23/24 10:20, Steven Rostedt wrote:
>> To put it this way. The bugs I'm fixing was for code in linux-next
>> where the bugs were never found. They only appeared when they went into
>> Linus's tree. So why put the fixes in linux-next, if it didn't catch
>> the bugs I fixed in the first place?
>
> The fix might be in a different part of the code, one that's stressed by
> -next testing even if the code with the original bug wasn't. So I don't
> think you can always assume that -next not catching the original bug means
> it can't catch a bug in the fix?
+1 to this and the "compile failures on obscure architectures or
configs" from Geert.
A -fixes branch in -next also makes a few things easier for regression
tracking:
* I only have to check *one* place instead of one or two hundred to see
if a regression fix is heading towards mainline or stuck somewhere.
* I can see if people accidentally queued regression fix for the current
or the next cycle when it should be the former (some subsystems make
this hard or impossible).
Ciao, Thorsten
Powered by blists - more mailing lists