On Fri, 31 Jan 2020 10:18:34 +0100 David Hildenbrand [off-list ref] wrote:

On 31.01.20 05:40, Andrew Morton wrote:

quoted

On Tue, 3 Dec 2019 14:36:38 +0100 Oscar Salvador [off-list ref] wrote:

quoted

On Mon, Dec 02, 2019 at 10:09:51AM +0100, David Hildenbrand wrote:

quoted

@Michal, @Oscar, can some of you at least have a patch #5 now so we can
proceed with that? (the other patches can stay in -next some time longer)

Hi, 

I will be having a look at patch#5 shortly.

Thanks for the reminder

Things haven't improved a lot :(

mm-memmap_init-update-variable-name-in-memmap_init_zone.patch
mm-memory_hotplug-poison-memmap-in-remove_pfn_range_from_zone.patch
mm-memory_hotplug-we-always-have-a-zone-in-find_smallestbiggest_section_pfn.patch
mm-memory_hotplug-dont-check-for-all-holes-in-shrink_zone_span.patch
mm-memory_hotplug-drop-local-variables-in-shrink_zone_span.patch
mm-memory_hotplug-cleanup-__remove_pages.patch

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

Now, this is an uncomfortable situation for you and me. You have to ping
people about review and patches are stuck in your tree. I have a growing
list of patches that are somewhat considered "done", but well,
not-upstream-at-all. I have patches that are long in RHEL and were
properly tested, but could get dropped any time because -ENOREVIEW.

Our process nowadays seems to be, to only upstream what has an ACK/RB
(fixes/features/cleanups).

Yes, we've been doing this for a couple of years now.  I make an
exception for Vitaly's zswap patches because he appears to be the only
person who knows the code (since Harry's internship ended).

I think this is the first time we've hit a significant logjam. 
Presumably the holiday season contributed to this.

It isn't clear to me that we've gained much from this policy.  But
until this cycle I've seen little harm.

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.

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.