Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Andy Shevchenko]

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:

..

> >>>>> 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.

Oh, yes, our processes are completely non-ideal. Once I tried to micro-optimize
the way of Cc'ing people for the patches to avoid waste of resources and you
know what? This is a dead end. I gave up, so I don't care anymore and don't
buy this argument anymore. If people are serious about this, they should be
serious consistently.

For your reference:
20240423132024.2368662-1-andriy.shevchenko@xxxxxxxxxxxxxxx

> > 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. 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? I haven't found in the documentation
the checklist which I can count numbers, compare with a table and have
a clear answer "yes, I have do it".

-- 
With Best Regards,
Andy Shevchenko