Date: Tue, 21 May 2024 20:41:02 +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 17:27, Andy Shevchenko wrote:
> On Tue, May 21, 2024 at 05:14:07PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
>> 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:
> [...]
>>> 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
> 
> "For urgent regressions, consider asking Linus to pick up the fix straight from
> the mailing list: he is totally fine with that for uncontroversial fixes.
> Ideally though such requests should happen in accordance with the subsystem
> maintainers or come directly from them."
> 
> The first thing I'm not so comfortable with is that Bart as a subsystem
> maintainer will be by-passed.

Well, that's why the last sentence you quoted is there; but yeah, the
"sub-subsystem" case it only kinda indirectly covered there. I can add
something about it if people feel that this is needed. But in the end
I'd say in this case Bart should be involved or the one that feeds this
to Linus. We'll see soon how both react to your PR. Thx for that BTW!

> The second one, is the metrics of urgency.
> I can assume that something from a TIP tree is really urgent and they
> even have established fast track for ages. But why do you think this fix
> is of the same level of urgency? 

We get into "best to ask Linus directly" territory here. I suspect
things for him boil down to "a fix is a fix; if it was reviewed and
ideally in next for ~2 days, let's just merge it to get rid of the
regression, unless there are strong reasons to wait a bit more (for
example if the fix is dangerous and better should be in -next somewhat
longer)".

Ciao, Thorsten

Powered by blists - more mailing lists