On Tue, Jul 14, 2026 at 10:57:51AM -0700, Andrew Morton wrote: > On Tue, 14 Jul 2026 09:09:51 -0700 Stanislav Kinsburskii > <[email protected]> wrote: > > > On Mon, Jul 13, 2026 at 03:45:35PM -0700, Andrew Morton wrote: > > > On Mon, 13 Jul 2026 13:57:55 -0700 Stanislav Kinsburskii > > > <[email protected]> wrote: > > > > > > > > > I rebased this series on top of mm-new right before sending it out. > > > > > > Should I have used a different branch? > > > > > > > > > > mm-new is good - Sashiko attempts that. But it's changing rapidly at > > > > > this point in the development cycle. > > > > > > > > > > > > > I’d like to send another revision addressing a few comments and also > > > > replace the `max/max_t` check with something simpler. > > > > > > > > Which branch should I base it on so that Sashiko can apply it > > > > successfully? > > > > > > mainline Linus would be safest. > > > > > > > Looks like linux-next/master has been updated with the v8 of the series. > > That's because v8 is in mm.git's mm-unstable branch. > > > I have v9 with a few small fixes, but it is too late to send it out already? > > It's called "unstable" for a reason! Material in mm-unstable is still > under review, test and the latest stages of development. Getting > things finalized for movement into the non-rebasing mm-stable branch, > then into mainline. > > So altering or replacing patchsets while they're in mm-unstable is > perfectly OK and expected. > > > If it's not, then what should I base it on? > > Well it's a bit tricky to replace a series when it's in mm-unstable. > One can do a git-checkout of the commit which precedes the v8 series. > Or base on current Linus mainline, which usually works out. > > Sending little fixup patches against what's presently in mm-unstable > also works. I'll queue each one immediately behind the patch which it > alters then squash them into their parent patch before moving the series > into mm-stable. > > A third alternative is for me to drop v8 from mm-unstable, then you > wait until that has propagated onto the servers or into linux-next, > then base on that. This approach is OK but I kinda unprefer it because > there's a bit of latency and it makes it harder for me to prepare my > "here's how v9 altered mm.git" summaries. > > > Which would you prefer?
Well, given that Sashiko didn’t pick up my series based on mm-new, I’d prefer to send a few follow-up patches in the hope that they will be reviewed in the context of the original series. Thanks, Stanislav
