On Tue, Jan 06, 2026 at 10:12:49AM -0800, Andrew Morton wrote: > On Tue, 6 Jan 2026 11:51:49 +0000 Lorenzo Stoakes > <[email protected]> wrote: > > > I'm not sure if the git repos are lagging vs. quilt, but as reported this > > patch breaks the VMA tests, and the tests are _still_ broken. > > > > Yet it's still in mm-new, mm-unstable, and even mm-hotfixes-unstable. > > > > This is interfering with my work, can we please drop this. > > > > Also the v3 is currently being debated, so surely should have been dropped > > until we have this resolved? > > Well. I don't drop fixes unless it's decided to be a non-issue or > unless a better fix is available.
Even if it breaks the build and that's been reported on-list? > > I've done this for ever - I've held onto "wrong" fixes for *years*. > View this as a weird issue-tracking system for a project which has no > issue-tracking system. It's to prevent issues from falling through > cracks and getting lost. I think a lot of the issue is these processes seem to work to you but those on the ground are finding them not to work. The kernel today is not the same as the kernel X years ago, esp. in terms of sheer volume. Having a patch that none of the relevant maintainers/reviewers have seen land in an -rc out of the blue is a really serious problem. Also it was taken 2 months after it was submitted, so nobody could have _possibly_ picked this up by reading the list. This is why I am really underlining this case. Again, requiring an M signoff fixes this completely. No patch should be merged without review, most certainly not one expedited to an -rc. > > It's unfortunate that this one causes disruption so I guess I'll loudly > comment it out and track the issue that way. > I think we need a better approach, yes. We in mm are really very responsive compared to most, I think asking people to wait and resend if somehow it got missed is considerably saner than 'well I'll take any patch purporting to be a fix from anyone so we keep track of stuff'. Cheers, Lorenzo
