On May 21, 2009, at 9:18 PM, Ojan Vafai wrote:
It makes no sense to me to r- a patch because reviewers don't have
time to review it. It put incentive in the wrong place. There are
other solutions to this problem that put incentive in the right
place (i.e. with reviewers). I don't necessarily think these are
good ideas, but I'll throw them out there.
1. If the review queue gets too large, close the tree to commits
until the queue is at 80% of that too large number.
2. Automate landing commits (e.g. click a button off the commit
queue) so that it's easier to land commits and keep the commit queue
small.
3. Give some kind of very visible notice on the waterfall when the
review queue gets too large (e.g. make the background color of the
whole page red).
4. Auto-assign reviews that haven't gotten reviewed after two weeks
to a reviewer and have that person be responsible for reviewing it
in a timely manner (this gives personal responsibility over the
queue length instead of the current distributed responsibility).
I'm sure there are a ton of other possible solutions to this problem
that don't punish people sending patches who have little control
over this situation. I imagine doing 3 and 4 would make a
significant difference.
I discussed the review backlog with Mark Rowe earlier, and we came up
with another idea that may help. This would be to categorize the
review queues. Perhaps we could get bugzilla to show a separate review
queue per component. So for example there would be queues for "CSS",
"JavaScriptCore", "WebKit Qt", etc. Then we could assign specific
people to be responsible for that queue. That doesn't mean these are
the only people who can review, but we would know who to badger if
certain queues get backlogs.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
