Message-ID: <nfui5woq5n4lc4xggsflvjqr3gmukfzo64ejxrg4o6iq6ud4ju@rctq63kb43wb>
Date: Thu, 21 Nov 2024 04:03:46 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Michal Hocko <mhocko@...e.com>
Cc: Shuah Khan <skhan@...uxfoundation.org>, 
	Dave Chinner <david@...morbit.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Christoph Hellwig <hch@....de>, Yafang Shao <laoar.shao@...il.com>, jack@...e.cz, 
	Christian Brauner <brauner@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>, 
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, 
	"Serge E. Hallyn" <serge@...lyn.com>, linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, 
	linux-bcachefs@...r.kernel.org, linux-security-module@...r.kernel.org, 
	linux-kernel@...r.kernel.org, "conduct@...nel.org" <conduct@...nel.org>
Subject: Re: review process (was: underalated stuff)

On Thu, Nov 21, 2024 at 09:43:21AM +0100, Michal Hocko wrote:
> On Wed 20-11-24 17:39:09, Kent Overstreet wrote:
> > Michal's (as well as Steve's) behaviour in the memory allocation
> > profiling review process was, in my view, unacceptable (this included
> > such things as crashing our LSF presentation with ideas they'd come up
> > with that morning, and persistent dismissive axegrinding on the list).
> > The project was nearly killed because of his inability to listen to the
> > reasons for a design and being stubbornly stuck on his right to be heard
> > as the maintainer.
> 
> Couple of entry points that might be helful for that.
> https://lore.kernel.org/all/YxBc1xuGbB36f8zC@dhcp22.suse.cz/
> I have expressed my concerns and set expectations to move the
> work forward. I've had couple of back and forth with Suren about
> specifics of overhead assumptions from the stack unwinding IIRC. 
> 
> For the first non-RFC version my feedback was
> https://lore.kernel.org/all/ZFIMaflxeHS3uR%2FA@dhcp22.suse.cz/#t
> not really "maintenance burden only" but a request to show that alternative
> approaches have been explored. It was not particularly helpful that you
> had expected tracing people would implement the feature for you.
> https://lore.kernel.org/all/20230503092128.1a120845@gandalf.local.home/
> Other people have also expressed that this is not completely impossible
> https://lore.kernel.org/all/ZFKNZZwC8EUbOLMv@slm.duckdns.org/
> The rest of the email thread is mostly a combat zone that I have avoided
> participating as much as possible.
> 
> I didn't have any reaction to v2 at all.
> 
> v3 was aiming to be merged and I've stepped up as there was no single
> review at the time https://lore.kernel.org/all/Zctfa2DvmlTYSfe8@tiehlicka/
> 
> I admit that I was really open that I do not like the solution and I've
> said reasons for that. Allocator APIs have always been a large mess of
> macros, static inlines that makes it really far from free to maintain
> and alternative ways should be considered before going that route.
> 
> I was also clear that support by MM people was necessary to get this
> merged. I have explicitly _not_ NAKed the series and backed off for you
> guys to gain that support. 
> 
> So essentially there was a clear outline for you and Sure how to achieve
> that.
> 
> I would really like to hear from other maintainers. Is tnis really
> unacceptable maintainer behavior? I am OK to apologize but the above is
> in line of my understanding of how to ack properly.

I wonder if I was reading too much into what you were saying in the
off-list thread, when I said "argument to authority". Can you tell me if
this might be closer to the mark?

If I read you correctly, when you said you were "voicing your concerns",
I took it as you being pushy because that was the effects: I need you to
take me at my word, because you didn't see everything behind the scenes,
that this did derail and nearly kill the project.

But I should've been taking you at your word, that you just really were
that concerned.

I think the best way I can explain this issue is with an analogy to
parenting: when we're parenting, our first and foremost job isn't really
to make sure there's a roof, shelter, food - that part is easy in
today's world. The main job really is to make sure that people feel
safe, that they can go out and explore the world without being
terrified.

In order to do that, we have to master our own fears, we can't be
projecting them all the time.

Being a maintainer, or any kind of leader, is the exact same thing. My
big lesson on this was watching Andrew, back during the process of
merging MGLRU - I couldn't believe at the time how chill he was about
it. But he understood the process, and he's a master at this.

Part of mastering our fears in a group setting like this is learning to
trust other people.

It's not that your concerns didn't have any validity - but we were
already doing as much as we could to address them, and you didn't show
any trust that we, I especially, knew what we were doing. And that led
to a _lot_ of wasted effort down blind alleys that I already knew
weren't going to work.

I think that may be what this is really about, sometimes you do have to
trust that people know what they're doing; you share your knowledge if
you have knowledge to share, otherwise you have to back off and let
people do their work. Otherwise the whole thing breaks down and no one
can get anything done.

The main thing is I just want to ask yourself if you could have done
anything better in the memory allocation profiling process. I don't need
you to apologize for anything specific, if you can just try to work
better together in the future that's all I need.

Powered by blists - more mailing lists