On Mon, Mar 03, 2025 at 03:05:47PM +0100, Christoph Hellwig wrote: > On Mon, Mar 03, 2025 at 11:42:12AM +0100, Carlos Maiolino wrote: > > The biggest change here is that for-next will likely need to be rebased > > more often than today. But also patches will spend more time under testings > > in linux-next and everybody will have a more updated tree to work on. > > FYI, what other trees do is to keep separate branches for the current > and next release, i.e. right now: for-6.14 and for-6.15 and merge those > into the for-next or have both of them in linux-next (e.g. for-linus and > for-next). In that case most of the time you don't need to rebase at > all. Instead you might occasionally need to merge the current into the > next tree to resolve conflicts, and Linus is fine with that if you > document the reason for that merge. This is pretty much aligned with my intentions, I haven't looked close yet how other subsystems deals with it, but by a few releases now, I keep a xfs-fixes-$ver branch which I collect patches for the current version, so adding a new branch for the next merge window is what I aimed to do with xfs-6.15-merge. The question for me now lies exactly on how to synchronize both. You partially answered my question, although merging the current into next sounds weird to me. If I merge current into next, and send Linus a PR for each (let's say for -rc7 and in sequence for the next merge window), Linus will receive two PRs with possibly the same patches, and yet, on the merge window PR, there will also be a merge commit from -current, is this what you're describing? Thanks for the input. > > > > > Also, I'm still thinking how to handle pull requests I receive. I try > > hard to not change the commit hashes from the PRs, so I'm still not sure > > how feasible it will be to keep the same hash ids from PRs giving more often > > than not I'll need to rebase the next merge tree on the top of fixes for the > > current -RC and in some cases, on top of other trees with dependencies. > > With the above you just keep the pull requests as-is. > > Sounds reasonable
