Re: Changes to XFS patch integration process

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

On Thu, Mar 06, 2025 at 06:08:41PM +0100, Christoph Hellwig wrote:
> 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.

Eliminating the possibility of such messes is also why I avoided doing
bugfixes and merge window prep whenever I could. ;)

--D