Re: Changes to XFS patch integration process

[Christoph Hellwig <hch@lst.de>]

On Thu, Mar 06, 2025 at 08:50:51AM +0100, Carlos Maiolino wrote:
> > 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.
> 
> I see what you mean, but from another POV, you'd be basing a PR on top of one
> series of patches, not on top of everything.

Well, while some subsystems have tons of topic branches that turns into
a mess really quickly.  So what Darrick said makes the most sense in
general.  There might be occasional corner cases where you'd want to
be more fine grained, but they should be very rare.

> 
> Today, what we have, is a relatively stable for-next branch, where we just
> really rebase when something goes wrong, so, usually, when I push things into
> for-next, I've had it tested for a big while.
> 
> Per my conversations off-list (specially with hch), is that this shouldn't be
> the purpose at all of for-next, but a testing branch where (almost anything) can
> go wrong, within reason of course. Please correct me if I'm wrong here.

I would expect for-next to have some amount of sanity testing.  But the
idea is indeed to have the code integrated with other kernel changes
rather sooner than later.

> 
> At the same time, I wish we have a branch that everybody can work with, which
> contains 'everything' staged, ready to go, so I'd do all the merge between
> current and next release myself into such branch. I think having a branch ready
> for people to work with is a maintainer's job, and people shouldn't be bothered
> by trying to figure out which branch they should use to base their patches on
> top.
> 
> I'm hoping to use the master's branch for that if nobody has any objection.

Using master is really confusing.

As I said earlier and Darrick also said the most usual thing is
to have one branch for $CURRELEASE fixes and one for $NEXTRELEASE
development work.  for-next is then a temporary merge of those two.
If you need $CURRELEASE changes in $NEXTRELEASE to avoid a mess, you
either rebase $NEXTRELEASE (usually earlier in the merge window) or
pull the $CURRELEASE into $NEXTRELEASE with a well-documented
merge commit message documenting why it had to be done.