On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti <[email protected]> wrote: > Hi Michael, > >> On 25 Nov 2014, at 01:57, Michael Still <[email protected]> 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. Michael -- Rackspace Australia _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
