Le 24/09/13 23:56, C. Scott Ananian a écrit :
Our core developers get a lot of patches to review. Once something drops down past the first page in Gerrit, it's lost forever.
I have enough people asking me for review that I only rely on my Gerrit dashboard. So indeed, old patches are usually out of my view.
Last time I looked at the rotting changes in mediawiki/core, most of them received some reviews and are pending actions from the original author. We should probably triage them and then either finish the code or abandon it.
Backing up here, I'm assuming that our focus is on fostering new developers. Old hands know who to add as reviewers, and know to pester them if they don't get a review in a reasonable time. I'm wondering if there's some way the bot can shepherd the review process a little further past the "add reviewers" stage.
For example, can we identify "new contributors" -- those with less than N patches merged, say? Have the bot target those for help with reviewers, and then maintain, say, a status board where we can keep an eye on those patches and make sure they make it through the process?
The OpenStack Foundation (they use Gerrit and a similar workflow of core people approving changes), has build a review dashboard that assign a score to changes:
http://status.openstack.org/reviews/
Related code is on github:
https://github.com/openstack-infra/reviewday#reviewday
The score algorithm is in reviewday/mergeprop.py [1]. As an example a regression hotfix get a score of 350 while a minor feature get 35. As the patch get older, it will receives additional points to bump it.
They then have all core people on a rolling one day duty where their role is to approve changes, assign reviewers and ask them to do reviews. That is tedious, but only for a day:
https://wiki.openstack.org/wiki/Nova/ReviewDays
We can surely reuse reviewday for our own use, that will need some code written to interact with Bugzilla to fetch the keywords/priority and assign scores.
I am to busy to babysit such a project on a labs instance, but will be more than happy to get the change merged upstream if need be (tip folks are in #openstack-infra).
[1] https://github.com/openstack-infra/reviewday/blob/master/reviewday/mergeprop...