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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> 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.

[...]

>> 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






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux