Linux IOMMU Development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Joerg Roedel <joro@8bytes.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	pr-tracker-bot@kernel.org, iommu@lists.linux.dev,
	open list <linux-kernel@vger.kernel.org>,
	Will Deacon <will@kernel.org>
Subject: Re: [git pull] IOMMU Updates for Linux v6.13
Date: Mon, 2 Dec 2024 11:12:31 -0400	[thread overview]
Message-ID: <20241202151231.GF773835@ziepe.ca> (raw)
In-Reply-To: <Z0WtI9-Xxr1eY7Av@8bytes.org>

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

  reply	other threads:[~2024-12-02 15:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26  1:45 [git pull] IOMMU Updates for Linux v6.13 Dmitry Safonov
2024-11-26  1:51 ` Dmitry Safonov
2024-11-26  2:45 ` Linus Torvalds
2024-11-26 11:12   ` Joerg Roedel
2024-12-02 15:12     ` Jason Gunthorpe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-11-22  8:17 Joerg Roedel
2024-11-23  4:10 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241202151231.GF773835@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=0x7f454c46@gmail.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pr-tracker-bot@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox