On Fri, Mar 27, 2026 at 10:52:24AM +0000, Lorenzo Stoakes (Oracle) wrote: > 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.
I didn't see there was a v2 in-reply-to here sorry. So in this case less fix patch more: 1. We shouldn't automatically take stuff to mm-unstable until it's settled 2. We should have clear separate branches for stuff-for-7.1 and stuff-for-7.2 3. We should build test stuff (!) 4. We should root cause the source of problems and update the thing that cause. Part of the problem here is that mm-unstable is a totally unreliable base. Not as bad as mm-new, but it's forgiveable that Audra didn't see Chris Down's patch there because who knows when that went in etc. if we had a for-7.1 git branch that only got stuff that had settled we'd not have this issue. And we could have a for-7.2 git branch for stuff that's arrived late. We could have: mm-untested (was mm-new) mm-under-review (was mm-unstable) -> THIS doesn't go to -next mm-for-7.1 (was mm-stable) -> THIS goes to -next mm-for-7.2 (fresh and new!) -> THIS only goes to -next next cycle And workflow could be: -> patch comes in go straight to mm-untested - we are undiscerning [ make sure series gets build tested + self tests + etc ] goes to mm-under-review WEEKLY: Stuff that has sub-M signoff and seen no further issues -> for-7.1 (i.e. next release) if it's <= rc4 and no other reasons to hold off OR for stuff that doesn't fit the rc4/no other reason criteria -> for-7.2 if signoff and no issues If things get reviewed and respun -> back to mm-untested until tests pass no matter tags -> (if stable) can jump right to for-7.1/for-7.2 if signed off already. if not then mm-under-review This way we reduce chance of late yank, give reasonable rebase target of for-[release you are interested in], documents and simplifies the process. Thoughts?... Cheers, Lorenzo
