[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241202151231.GF773835@ziepe.ca>
Date: Mon, 2 Dec 2024 11:12:31 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Joerg Roedel <joro@...tes.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Dmitry Safonov <0x7f454c46@...il.com>, pr-tracker-bot@...nel.org,
iommu@...ts.linux.dev, open list <linux-kernel@...r.kernel.org>,
Will Deacon <will@...nel.org>
Subject: Re: [git pull] IOMMU Updates for Linux v6.13
On Tue, Nov 26, 2024 at 12:12:35PM +0100, Joerg Roedel wrote:
> On Mon, Nov 25, 2024 at 06:45:00PM -0800, Linus Torvalds wrote:
> > Those octopus merges may look cool, but you should never use an
> > octopus merge for anything that has any conflicts, because they are
> > hard to get right. Joerg clearly didn't get that one right.
>
> Yeah, sorry, my bad. This time around there were unusually many
> conflicts between the topic branches, which also forced me to create
> two merge commits to put everything together. In this process I
> overlooked that the iommu_present() definition slipped through.
I know we talked about this before, but I think the topic branches and
octopus merge flow is troublesome. This cycle had lots of all-driver
work and it is a pain working like this.
We rarely seem to toss stuff out, it would be OK to just revert it, or
run a delayed two step promotion like Andrew does.
I especially don't like that this flow recreates the octopus merge
whenever the branches change so there is no stable tree for people to
follow, or to submit patches on top of the current state of the tree.
IMHO the more traditional flow of just merging patches/PR forward on a
single branch works better.
Jason
Powered by blists - more mailing lists