On Tue, Jan 06, 2026 at 12:59:12PM -0800, Andrew Morton wrote: > On Tue, 6 Jan 2026 18:24:10 +0000 Lorenzo Stoakes > <[email protected]> wrote: > > > 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 addressed that. > > > > > > > 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. > > It isn't in -rc. It's in mm-hotfixes-unstable and it's marked "acks?", > which means not to go upstream without further consideration. > > > 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. > > That's why I grabbed it. Had I not done so, this issue would have been > lost. What I do *worked*. > > > > > > > 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'. > > If someone wants to step up and be MM issue tracking person then great. > I don't want to be that person. > > And let me reiterate: had I not done this, the issue Mikulas identified > would have remained unaddressed. >
I understand your point. I don't think anyone wants to see patches falling through the cracks. But we also don't want patches to get applied without any review. Perhaps it's time to deploy something like Patchwork to help track outstanding patches? -- Pedro
