Re: [PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier()

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Apr 08, 2022 at 10:07:50AM -0600, Alex Williamson wrote:
> On Fri, 8 Apr 2022 10:59:22 -0500
> Bjorn Helgaas <helgaas@kernel.org> wrote:
> 
> > On Fri, Apr 08, 2022 at 05:37:16PM +0200, Joerg Roedel wrote:
> > > On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote:  
> > > > You might consider using a linear tree instead of the topic branches,
> > > > topics are tricky and I'm not sure it helps a small subsystem so much.
> > > > Conflicts between topics are a PITA for everyone, and it makes
> > > > handling conflicts with rc much harder than it needs to be.  
> > > 
> > > I like the concept of a branch per driver, because with that I can just
> > > exclude that branch from my next-merge when there are issues with it.
> > > Conflicts between branches happen too, but they are quite manageable
> > > when the branches have the same base.  
> > 
> > FWIW, I use the same topic branch approach for PCI.  I like the
> > ability to squash in fixes or drop things without having to clutter
> > the history with trivial commits and reverts.  I haven't found
> > conflicts to be a problem.
> 
> Same.  I think I've generally modeled my branch handling after Bjorn
> and Joerg, I don't always use topic branches, but will for larger
> contributions and I don't generally find conflicts to be a problem.
> I'm always open to adopting best practices though.  Thanks,

I don't know about best practices, but I see most maintainers fall
somewhere on a continuum between how Andrew Morton works and how David
Miller/Linus work.

Andrew's model is to try and send patches that are perfect and he
manipulates his queue continually. It is never quite clear what will
get merged until Linus actually merges it.

The David/Linus model is that git is immutable and they only move
forward. Never rebase, never manipulate an applied patch.

Andrew has significantly reigned in how much he manipulates his queue
- mostly due to pressure from Linus. Some of the remarks on this topic
over the last year are pretty informative. So I would say changing
patches once applied, or any rebasing, is now being seen as not best
practice. (Indeed if Linus catches it and a mistake was made you are
likely to get a sharp email)

Why I made the note, is that at least in my flow, I would not trade
two weeks of accepting patches for topics. I'll probably have 20-30
patches merged already before rc3 comes out. I never have problems
merging rc's because when a rc conflicts with the next I have only one
branch and can just merge the rc and resolve the conflict, or merge
the rc before applying a patch that would create a conflict in the
first place. Linus has given some guidance on when/how he prefers to
see those merges done.

Though I tend to advocate for a philosophy more like DaveM that the
maintainer role is to hurry up and accept good patches - to emphasize
flow as a way to build involvement and community.

That is not necessarily an entirely appropriate approach in some of
the more critical subsystems like mm/pci - if they are broken in a way
that impacts a large number of people at rc1 then it can cause a lot
of impact. For instance our QA team is always paniced if rc1 doesn't
work on our test environments.

Cheers,
Jason