On Fri, 25 Jan 2019 at 23:12, Gian Merlino <g...@apache.org> wrote: > If enough other committers have already reviewed and accepted a patch, I > don't think it's fair to the author or to those other reviewers for > committing to be delayed by two weeks because another committer doesn't > have time to finish reviewing, but wants others to wait for them anyway.
It sounds like it's implied that the reviewer is irresponsible because he started reviewing a PR but "doesn't have time to finish reviewing". In fact, a reviewer could *have* time to finish reviewing and is willing to finish the review, but they don't have time *tomorrow*. A reviewer could have different duties and could slice only Y hours for reviews of Druid PRs every X days. X/(Y * number of PRs the reviewer is interested in at the moment) is how often (in days) a reviewer could pay attention to specific PR. I think we should respect that for some people, at least at some times, this value could grow to about 7. Saying that we shouldn't wait for those people creates a bias favoring most involved developers, and it's not necessarily a good bias, because sometimes outsider (or half-outsider) perspective is valuable. If we do releases every 3 months and the time between creating a release branch and the final release candidate is at least 3 weeks (historically), why there is an urge to commit anything faster. IMO the real source of unfairness in reviews is that reviewers generally prioritize the newest PRs rather than PRs that await for reviews the longest. The probability that somebody starts to review a PR decreases with time, while it should increase.
