[openstack-dev] [Nova] Frustrations with review wait times

Sandy Walsh sandy.walsh at rackspace.com
Wed Aug 28 14:15:24 UTC 2013

On 08/28/2013 10:58 AM, Thierry Carrez wrote:
> Robert Collins wrote:
>> So I'd like to throw two ideas into the mix.
>> Firstly, consider having a rota - ideally 24x5 but that will need some
>> more geographical coverage I suspect for many projects - of folk who
>> spend a dedicated time period only reviewing.
> We have been doing that in the past for Nova, with little success. The
> reason why "reviewday" is called "reviewday" is because... well... there
> were review days.
> The wiki page was a bit eaten by the wiki conversion, but you can still
> read it at:
> https://wiki.openstack.org/wiki/Nova/ReviewDays
> In the end, a strict rotation didn't work out because people just didn't
> review on their review day, but rather when they have one hour free
> waiting for a patch to pass gate or whatever. In the end, the rotation
> gave us way worse results than random ad-hoc reviewing, because people
> would stop reviewing on days other than their review day, and would
> regularly skip their review day altogether.
> Furthermore, there is some specialization going on: I prefer the two Xen
> experts in nova-core to review one hour every two days rather than one
> day every two weeks... because then Xen patches get better review
> roundtrip times.
> So I'm not convinced *at all* that a reboot of this would yield better
> results.


That said, I think the reason my reviews dropped off from Nova was not
having a dedicated day for it. But that was my fault, not the fault of
the process. With Ceilometer, I try to set aside one fixed day a week
for reviews (with moderate success ;)

>> Launchpad [the
>> project, not the site] did this with considerable success : every
>> qualified reviewer committed to a time slot and didn't *try* to code -
>> they focused on reviews.
> The key difference is that "every qualified reviewer" was employed by
> the same company, and the review day was enforced by their management.
> The amount of patches is also significantly lower, and there is less
> specialization effect.

More information about the OpenStack-dev mailing list