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