[openstack-dev] [Nova] Tracking Kilo priorities
mikal at stillhq.com
Tue Nov 25 00:35:13 UTC 2014
On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti
<apilotti at cloudbasesolutions.com> wrote:
> Hi Michael,
>> On 25 Nov 2014, at 01:57, Michael Still <mikal at stillhq.com> wrote:
>> First off, sorry for the slow reply. I was on vacation last week.
>> The project priority list was produced as part of the design summit,
>> and reflects nova's need to pay down technical debt in order to keep
>> meeting our users needs. So, whilst driver changes are important, they
>> doesn't belong on that etherpad.
>> That said, I think the best way to help us keep up with our code
>> review requirements is to be an active reviewer. I know we say this a
>> lot, but many cores optimize for patches which have already been
>> reviewed and +1'ed by a non-core. So... Code review even with a +1
>> makes a real difference to us being able to keep up.
> Thanks for your reply, we actually do quite a lot of cross reviews, with the
> general rule being that every patch produced by one of the Hyper-V team members
> needs to be reviewed by at least another two.
> The main issue is that reviews get lost at every rebase and keeping track of
> this becomes not trivial when there are a lot of open patches under review,
> mostly interdependent. It's not easy to keep people motivated to do this, but
> we do our best!
This is good news, and I will admit that I don't track the review
throughput of sub teams in nova.
I feel like focusing on the start of each review chain is useful here.
If you have the first two reviews in a chain with a couple of +1s on
them already, then I think that's a reasonable set of reviews to bring
up at a nova meeting. I sometimes see a +2 or two on reviews now at
the beginning of a chain, and that's wasted effort.
More information about the OpenStack-dev