Thread (75 messages) 75 messages, 9 authors, 2020-02-05

Re: [PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory

From: David Hildenbrand <hidden>
Date: 2020-01-31 10:37:19
Also in: linux-mm

quoted
quoted
The first patch has reviews, the remainder are unloved.
Trying hard not to rant about the review mentality on this list, but I'm
afraid I can't totally bite my tongue ... :)
I am afraid this is less about mentality than the lack of man power.
This is not a new problem. We have much more code producers than
reviewers.
It's part of the "take-and-not-give-back review mentality" and I hope
you "smelled" that the comment was not targeted at you.

[...]
quoted
Although it will make upstreaming stuff *even harder* and *even slower*,
maybe we should start to only queue patches that have an ACK/RB, so they
won't get blocked by this later on? At least that makes your life easier
and people won't have to eventually follow up on patches that have been
in linux-next for months.
I wouldn't mind if patched got merged to mmotm less pro-actively at all.
People tend to care less to follow up on patches that are in the queue
already from my past experience. And also it encourages to generate more
code than review.
The current process will at least encourage me in the long term to
generate less code (changes) as well. I consider patches that have not
been merged upstream as on my TODO list - and it seems to keep on
growing. (yes, there are people that fire-and-forget)

Then, I much rather prefer to just get no reply on my patches, ping two
times, and eventually dump them into the trash. As explained, will WHP
result in me generating less code changes overall. Problem partially
solved (at least one producer less) :)
This is certainly not a black or white of course. Some areas have barely
anybody for a review except for the person actively writing code in that
area so this really needs the case by case approach.
Yes.
Anyway this is not a new discussion or a new problem we are facing. I
believe that part of the problem is that the MM subsystem doesn't really
have official maintainers so there is nobody really responsible for
particular parts of the subsystem. Sure Andrew is merging patches based
on the review feedback or his gut feeling but I am afraid this is not
enough.
If we would have "official maintainers" would it really help (besides
Andrew having less stuff to do of course)? E.g., if you would pick up
the memory hotplug patches, you would still have to have a look at them
- it's still the producer-consumer imbalance (and you would have an even
higher workload).

But yeah, we should most probably finally have official maintainers. For
people sending patches, it's often not obvious whom to cc (and whom to
ping).

Smells like a "LSF/MM/BPF TOPIC", but as you said, it's not a new
problem/discussion. (I won't be around, so I can't bring that topic up)


Anyhow, my two cents.

-- 
Thanks,

David / dhildenb
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help