Message-ID: <4f1bcc8b-1795-4e3c-90a6-742cd8443396@leemhuis.info>
Date: Tue, 21 May 2024 17:14:07 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
 Laura Nao <laura.nao@...labora.com>, mika.westerberg@...ux.intel.com,
 linus.walleij@...aro.org, brgl@...ev.pl, kernel@...labora.com,
 linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
 linux-acpi@...r.kernel.org,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 "kernelci.org bot" <bot@...nelci.org>
Subject: Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to
 acpi_can_fallback_to_crs()

On 21.05.24 16:53, Andy Shevchenko wrote:
> On Tue, May 21, 2024 at 04:26:32PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 21.05.24 16:00, Andy Shevchenko wrote:
>>> On Tue, May 21, 2024 at 12:01:17PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>> On 13.05.24 12:02, Andy Shevchenko wrote:
>>>>> On Mon, May 13, 2024 at 11:56:10AM +0200, Laura Nao wrote:
>>>>>> Following the relocation of the function call outside of
>>>>>> __acpi_find_gpio(), move the ACPI device NULL check to
>>>>>> acpi_can_fallback_to_crs().
>>>>>
>>>>> Thank you, I'll add this to my tree as we have already the release happened.
>>>>> I will be available after v6.10-rc1 is out.
>>>>
>>>> Hmm, what exactly do you mean with that? It sounds as you only want to
>>>> add this to the tree once -rc1 is out -- which seems likely at this
>>>> point, as that patch is not yet in -next. If that's the case allow me to
>>>> ask: why?
>>>
>>> Because:
>>>
>>> - that's the policy of Linux Next (do not include what's not supposed to be
>>>   merged during merge window), Cc'ed to Stephen to clarify, it might be that
>>>   I'm mistaken
>>>
>>> - the process of how we maintain the branches is to have them based on top of
>>>   rc1 (rarely on other rcX and never on an arbitrary commit from vanilla
> 
> Note, besides above reasons the one is (was in this case as you noticed)
> to wait until dependencies laid down in the upstream.

Well, that can be a reason, sure. But I still wonder if Linus would have
preferred to get 49c02f6e901c and this fix for it in the same pull.
Sure, adding this fix would have been a late addition, but when it is a
fix and mentioned in the PR that from what I can see is no problem at
all for him.

>> Something like that is what I feared. And yes, some of that is true. But
>> the patch in this thread contains a Fixes: tag for commit 49c02f6e901c
>> which was merged during this merge window -- and that patch thus ideally
>> should (ideally after some testing in -next) be merge during the merge
>> window as well, to ensure the problem does not even hit -rc1.
> 
>> That's something a lot of subsystem master all the time. The scheduler
>> for example:
>>
>> https://git.kernel.org/torvalds/c/6e5a0c30b616bfff6926ecca5d88e3d06e6bf79a
>> https://git.kernel.org/torvalds/c/8dde191aabba42e9c16c8d9c853a72a062db27ee
>>
>> Other subsystems (perf, x86, net) do this, too. Not sure how they
>> exactly do that with git; I think some (most?) have a dedicated -fixes
>> branch (based on master and fast-forwarded after Linus merged from it)
>> for that is also included in next in parallel to their "for-next"
>> branch.  Stephen will know for sure.
> 
> This part of the kernel is not so critical as scheduler, but in general I agree
> that sooner we get this in is better.

Side note: with all those CIs that "sooner" became more important I'd
say, as I frequently see multiple CI systems running into and bisecting
problems -- which humans then look into and report, which is a waste of
time.

> The other thing, that we have 3 regressions
> now for very this code. And some of them are still under discussions.
> 
> Wouldn't be better to gather all fixes and send a bunch via proper process
> after rc1? 

Depends on the situation. As a general approach I'd say no, but there
definitely can be situations where that is wise.

> This will ensure that everything we know about is covered properly
> and processed accordingly,
> 
> In broader way, the process should be amended if you want a fast track for
> the patches like this. I'm on the second level here, Bart is the maintainer
> who sends PRs directly to Linus. Do we have anything like this?

Pretty sure Linus wants maintains to just fast-track things when needed
by sending an additional PR; he multiple times said that this is not a
problem.

But there is a way to fast track things: just ask Linus to pull a patch
from the list (e.g. in a reply to the patch while CCIng tim). He
multiple times said this is no problem for him, unless it becomes the
norm. This is documented in
Documentation/process/handling-regressions.rst /
https://docs.kernel.org/process/handling-regressions.html

Ciao, Thorsten

Powered by blists - more mailing lists