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

[David Hildenbrand]

>> I can understand this is desirable (yet, I am
>> not sure if this makes sense with the current take-and-not-give-back
>> review mentality on this list).
>>
>> 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.
> 
> The merge rate would still be the review rate, but the resulting merges
> would be of less tested code.

That's a valid point.

> 
>> Note: the result will be that many of my patches will still not get
>> reviewed, won't get queued/upstreamed, I will continuously ping and
>> resend, I will lose interest because I have better things to do, I will
>> lose interest in our code quality, I will lose interest to review.
>>
>> (side note: some people might actually enjoy me sending less cleanup
>> patches, so this approach might be desirable for some ;) )
>>
>> One alternative is to send patches upstream once they have been lying
>> around in linux-next for $RANDOM number of months, because they
>> obviously saw some testing and nobody started to yell at them once
>> stumbling over them on linux-mm.
> 
> Yes, I think that's the case with these patches and I've sent them to
> Linus.  Hopefully Michel will be able to find time to look them over in
> the next month or so.

I really hope we'll find more reviewers in general - I'm also not happy
if my patches go upstream with little/no review. However, patches
shouldn't be stuck for multiple merge windows in linux-next IMHO
(excluding exceptions of course) - then they should either be sent
upstream (and eventually fixed later) or dropped.

Thanks Andrew!

-- 
Thanks,

David / dhildenb