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
