On Thu, May 21, 2009 at 10:08 PM, Maciej Stachowiak <m...@apple.com> wrote:
> If you want to r- a patch for a reason, such as being too big, or having > feedback already that hasn't been addressed, that's fine. But I think it > would be a bad idea to reject patches just because they haven't been > reviewed for too long. And the other folks who have spoken up so far seem to > agree. > I'm on the fence overall, but I can understand eseidel's position, so I'll chime in so he's not all alone. To use that same bug analogy, Mozilla actually _did_ that with their bug database and found it extremely valuable. Closing old bugs meant that the 1% that have serious, interested parties behind them that could still reproduce spoke up, and those bugs stayed alive -- noticeably increasing the quality of the bug pool. While I don't think the same effect applies to reviews two weeks old, it certainly does after, say, two months -- and in the Chromium database I routinely ping people on old reviews that have languished and eventually close them. If the person submitting the patch is interested, and the message with the r- is clear, getting an r- that says "if this still applies please re-ping" is at the very worst an annoyance, not a disaster. If the timeout was increased from two weeks to one month, and coupled with a push that got the queue to zero patches and then implemented policies to help it stay low in the future (which both Chromium and Mozilla lack, so you don't feel too bad), I would be fully supportive. As-is, I'm not sure it helps as much, but I'm not ticked. PK
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
