quoted

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.

quoted

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