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