Am 22.05.2009 um 06:41 schrieb Maciej Stachowiak:
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.
I think this is a very wise idea. If we'd combine this with a "review
queue supervisor" per component it with certainly help to avoid
backlogs.
For instance the supervisor could get a mail all two weeks listing the
patches waiting for review. Either the supervisor takes care of the
review
or delegates to other reviewers. The idea is that at least someone
notices the queue is very long. The last times this came up on the
mailing list
I think it was either Eric or Maciej notifying the crowd about the
state of the review queue. This definately needs to be changed.
So, you get my voice for creating categorized review queues. The
positive side-effect is that I don't need to scan long time for
patches that interesst
me (aka. that I'm qualified for review), but rather get the list of
patches immediately in a single view.
I think it's great that Eric brought up this topic again, as I think
we can improve the situation much better with not that much effort.
Have a nice day,
Niko
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
