Re: [PATCH 5.10 v2 8/8] xfs: assert in xfs_btree_del_cursor should take into account error

[Luis Chamberlain <mcgrof@kernel.org>]

On Tue, Jun 07, 2022 at 11:35:50AM -0700, Darrick J. Wong wrote:
> On Tue, Jun 07, 2022 at 09:09:47AM +0300, Amir Goldstein wrote:
> > Regarding explicit ACKs, I wasn't sure what to do.
> 
> Me neither.  It feels a little funny to ACK a patch in a stable queue
> that I already RVB'd for upstream, but is that peoples' expectation?

I think that's up to us, in particular because we don't want bots to do this
work for XFS, and so we must define what we feel comfortable with.

How about this: having at least one XFS maintainer Ack each of the
patches for the intent of getting into stable? If no Acks come back
by *2 weeks* the stable branch maintainers can use their discretion
to send upstream to the stable team.

> > I incorporated your feedback and wrote my plans in this email [3]
> 
> I'm going to offer my (probably controversial) opinion here: I would
> like to delegate /all/ of the power and responsibility for stable
> maintenance to all of you (Amir/Leah/Chandan/etc.) who are doing the
> work.  What Amir did here (send a candidate patchset, take suggestions
> for a week, run the batch through fstests) is more or less what I'd
> expect from whoever owns the LTS backport process.

I'm happy to provide advice as a paranoid developer who has seen
the incredibly odd things come up before and had to deal with them.
People can either ignore it or take it.

> I've been pondering this overnight, and I don't agree that the above
> scenario is the inevitable outcome.  Are you (LTS branch maintainers)
> willing to put your names in the MAINTAINERS file for the LTS kernels
> and let us (upstream maintainers) point downstream consumers (and their
> bug report) of those branches at you?  If so, then I see that as
> effective delegation of responsibilities to people who have taken
> ownership of the LTS branches, not merely blame shifting.

*This* is why when I volunteered to do xfs stable work a long time ago my
own bar for regression testing was and still remains *very high*. You really
need to put the fear in $deity in terms of responsibility because
without that, it is not fair to upstream developers for what loose
cannons there are for stable candidate patches for a filesystem. As
anyone doing "enterprise" could attest to, *that* work alone requires a
lot of time, and so one can't realistically multitask to both.

It is also why this work stopped eventually, because I lost my test rig after
one $EMPLOYER change and my focus was more on the "enterprise" side at SUSE.
It is why after yet another $EMPLOYER change this remains a long
priority, and I try to do what I can to help with this.

If we care about stable we need to seriously consider a scalable
solution which *includes* testing. And, I also think even the "bot"
enabled stable fixed filesystem could benefit from these best practices
as well.

> If yes, then ... do as you like, you're the branch owner.  I expect
> things to be rocky for a while, but it beats burning myself out with too
> many responsibilities that I have not been able to keep up with.  It's
> probably better for the long term stability of each LTS branch if
> there's one or two people who are really familiar with how that LTS has
> been doing, instead of me trying and failing to multiplex.
> 
> Also, as Greg points out, at worst, you /can/ decide to revert something
> that initially looked good but later turned out smelly.

If testing is paranoid the chances of these reverts are reduced.
The reason for paranoia is reasonably higher for filesystems since
we don't want to break a user's filesystem. It is up to each stable
branch maintainer to decide their level of paranoia, as they incur
the responsibility for the branch.

  Luis