On Fri, May 22, 2026 at 10:20 AM Lorenzo Stoakes <[email protected]> wrote: > > On Fri, May 22, 2026 at 10:08:19AM -0600, Nico Pache wrote: > > On Fri, May 22, 2026 at 9:17 AM Lorenzo Stoakes <[email protected]> wrote: > > > > > > On Fri, May 22, 2026 at 09:07:29AM -0600, Nico Pache wrote: > > > > Whoops I manually changed the coverletter subject to reflect that this > > > > in on mm-hotfixes-unstable but never updated the others... > > > > > > > > Hopefully that is ok. Just a small mistake. Base commit is referenced > > > > here. > > > > > > It's not ok, this isn't suitable for a hotfix in any way shape or form? > > > > > > As you know, because we told you :) May has been difficult because of > > > conferences, holidays (and in my case burnout recovery). > > > > > > And unfortunately the series seems to have needed quite a bit of review > > > again > > > (my suggestion to you would be to ensure you don't make major changes, > > > only > > > small incremental ones on the basis of review feedback). > > > > > > So this isn't viable for 7.2, and we'll have to target 7.3. Therefore > > > there > > > was no rush. > > > > > > Also please don't spring a respin on this series on us without discussion > > > first, with people away and (frankly) the amount of work involved here, > > > you're going to have to accept the pace that workload/availability > > > permits. > > > > > > Adding spurious hotfixes tags doesn't help anything :) please don't do > > > that > > > again. > > > > Hi, > > > > Sorry for the confusion but Andrew and I spoke about this before I > > sent it, and he confirmed that I should send it against this tree to > > prevent merge conflicts. > > > > Because Zi's series depends on this, and this is already in the mm > > tree, choosing a candidate before my commits was best to prevent merge > > conflicts. > > There's some kind of confusion here. > > This series isn't suited for 7.2. > > Sorry but Zi's series, unless it depends on functionality here, will have > to be rebased. > > People have been at conferences, people have been on leave, I've had to > pace myself for health reasons and it seems there's been more than simply > review comment-based changes happening here. > > (Again I strongly encourage, at this stage, to ONLY be making changes based > on review, not adding ANYTHING else or changing ANYTHING else to avoid > delays :)
All the changes are based on review points. Very small changes in this version; the largest being the one that you specifically argeed too. > > Also - shouldn't mm-unstable already have mm-hotfixes-unstable in it? > > I think in mm-next we will have an stable branch, that everything is > based on, where things go once review is complete and things are mergeable. > > And a separate hotfixes branch based on Linus's tree. > > That would avoid issues like this :) Im sorry im new to this, but I really dont think this tiny error, and something that I'd confirmed with Andrew beforehand deserves NAKing and defering it. Ive worked through my PTO to clean up some of these review nits just to get it in 7.2. I even through this through my rounds of testing today before resending. > > > > > The intent wasn't that this is a hotfix, just that this was the > > closest base before the v17 that is already in the tree. > > The convention is that [PATCH ... <branch>] indicates the target of the > changes. Putting the hotfixes branch there implies it's a hotfix. Sorry I thought the <branch> was what base you used. > > So please be careful with that in future :) Yes will do for sure. > > > > > Sorry for the confusion, hopefully Andrew can still apply it to the > > correct tree. > > I'm not even sure what's best for that at this stage given we have > conflicts and this has to be delayed until 7.3. > > I wonder if given that we should not have this in mm-unstable at all and > just wait it out until the next cycle begins? Review can happen > concurrently. I still dont see why this has to be deferred, I was working with Andrew to prevent merge headaches. -- Nico > > > > > -- Nico > > > > > > > > Thanks, Lorenzo > > > > > > > Thanks, Lorenzo >
