On 31.01.20 05:40, Andrew Morton wrote: > On Tue, 3 Dec 2019 14:36:38 +0100 Oscar Salvador <osalvador@xxxxxxx> wrote: > >> On Mon, Dec 02, 2019 at 10:09:51AM +0100, David Hildenbrand wrote: >>> @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). 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. 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. -- Thanks, David / dhildenb
