Re: Changes to XFS patch integration process

["Darrick J. Wong" <djwong@kernel.org>]

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