Re: [PATCH] selftests/mm: add CONFIG_DEBUG_FS to the config fragment

[David Hildenbrand (Arm)]

On 11/7/26 13:42, Sasha Levin wrote:
> On Fri, Nov 06, 2026 at 10:32:27PM +0100, David Hildenbrand (Arm) wrote:
>> On 11/6/26 19:52, Sasha Levin wrote:
>>>
>>> Thanks! It looks like this one landed on both thp-7.5.misc and
>>> core-7.5.misc:
>>>
>>>   31ea5515bf59 ("selftests/mm: add CONFIG_DEBUG_FS to the config fragment")
>>>   194b63198811 ("selftests/mm: add CONFIG_DEBUG_FS to the config fragment")
>>>
>>> Was the thp-7.5.misc one meant to be the split_huge_page_test skip patch?
>>>
>>>   https://lore.kernel.org/all/20261105030242.1241448-1-sashal@xxxxxxxxxx/
>>
>> Fixes.
>>
>> b4 shazam gets confused when patches are sent in reply to patches.
>>
>> Which is why we shouldn't do it ;)
> 
> Remember my gripe about how subsystems are starting to have more and more
> custom rules around process? :p

Let's not twist my words. I said "we shouldn't do it", there are no rules around
it and also I don't want any rules around that.

And the example below (bug vs. bug report) makes perfect sense.

> 
> Our docs currently say (Documentation/process/submitting-patches.rst):
> 
> 	Explicit In-Reply-To headers
> 	----------------------------
> 
> 	It can be helpful to manually add In-Reply-To: headers to a patch
> 	(e.g., when using ``git send-email``) to associate the patch with
> 	previous relevant discussion, e.g. to link a bug fix to the email with
> 	the bug report.
> 
> I suppose it's okay for parts of the kernel to deviate from the "standard", but
> it's a bit hard to keep track of these preferences.

Just to be clear, patch in reply to patch to me is something different than
patch in reply to discussion.

People tend to ignore certain patches because it's not relevant for them;
burying something related but more generic in there is not always the best idea.

But it all doesn't matter, because there are not any such strict rules and I
just have to learn to properly use b4 :P

-- 
Cheers,

David