On Mon, Mar 03, 2025 at 04:00:39PM +0100, Carlos Maiolino wrote: > 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. Separate branches for 6.14 and 6.15 that then get merged into a for-next is what I did when I had separate trains running at the same time. Most of the time I just rolled the post-rc6 fixes into the next release, so I usually only dealt with one at a time. (to some grumbling) > 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? If I had a for-6.14 and a for-6.15 branch, I'd base the PRs off of those branches, not the for-next branch itself. > 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 Or you can ask the PR submitter to rebase off latest for-6.15 and handle the merge themselves. --D
