Date: Tue, 21 May 2024 19:50:01 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: 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 Tue, May 21, 2024 at 06:27:42PM +0300, 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:

..

> > >>>>> 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@...ux.intel.com
> 
> > > 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".

FWIW, I have just sent a PR to Linus and GPIO maintainers with this one
included. Hopefully everybody is now happy.

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists