[webkit-dev] Review Queue

[Peter Kasting]

On Thu, May 21, 2009 at 10:08 PM, Maciej Stachowiak <mjs at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090521/85aa921f/attachment.html>