On Fri, Mar 27, 2026 at 10:52:24AM +0000, Lorenzo Stoakes (Oracle) wrote: > Audra - to be clear this is discussion about mm process not your patch > specifically. > > OK again I'm starting to think we just shouldn't support fix-patches at all > any > more. > > This is an example of a change being done in a fix-patch that's _really_ > causing issues. > > Because this has now caused mayhem in mm-unstable and the 'kinda stable-ish' > branch now won't compile any self tests. > > The fix in [0] on Chris Down's test series was for too many args to this > function (the patch changing this should have been rebased on mm-unstable and > changed Chris's caller there). > > But now since this patch above ^ got yanked, that 'fix' has stayed in place > and > now no mm self tests compile. > > And now we see [1], hilariously. > > [0]:https://lore.kernel.org/linux-mm/[email protected]/ > [1]:https://lore.kernel.org/linux-mm/[email protected]/ > > This kind of massive levels of confusion and 'I am just trying to run some > self > tests on what-should-be-for-next' is just not helpful... > > I think we need a for-next branch that actually consists of stuff we genuinely > mean to take (i.e. review has settled) instead of 'literally everything > because > we move stuff from mm-new unconditionally'. > > Anyway we should revert the fix in [0] because it's broken now. > > Cheers, Lorenzo
BTW, even _at_ the fix-patch commit hash (28edd9c5a25c) the test builds fail. So I wonder if it might be good to at least do build checks of the kernel and also tests (tools/testing/selftests/mm and tools/testing/vma) before applying a patch? As that would have caught this right away. Breaking the build should be considered a no-no. Cheers, Lorenzo
