On Thu, Nov 14, 2013 at 5:59 PM, Robert Collins <robe...@robertcollins.net>wrote:
> > Total reviews: 10705 (118.9/day) > Total reviewers: 406 > Total reviews by core team: 5289 (58.8/day) > Core team size: 17 > New patch sets in the last 90 days: 7515 (83.5/day) > > This is the really interesting bit. Remembering that every patch needs > - at minimum - 2 +2's, the *minimum* viable core team review rate to > keep up is patch sets per day * 2: > 30 days: 132 core reviews/day > 90 days: 167 core reviews/day > > But we're getting: > 30 days: 42/day or 90/day short > 90 days: 59/day or 108/day short > > One confounding factor here is that this counts (AIUI) pushed changes, > not change ids - so we don't need two +2's for every push, we need two > +2's for every changeid - we should add that as a separate metric I > think, as the needed +2 count will be a bit lower. > > So I thought that can make quite a difference to the calculations you made below so just for fun I added a few more stats ( https://review.openstack.org/#/c/56380/) and got: Total reviews: 10751 (119.5/day) Total reviewers: 405 Total reviews by core team: 5312 (59.0/day) Core team size: 17 New patch sets in the last 90 days: 7501 (83.3/day) Changes involved in the last 90 days: 1840 (20.4/day) New changes in the last 90 days: 1549 (17.2/day) Changes merged in the last 90 days: 1120 (12.4/day) Changes abandoned in the last 90 days: 395 (4.4/day) Changes left in state WIP in the last 90 days: 18 (0.2/day) Queue growth in the last 90 days: 16 (0.2/day) Average number of patches per changeset: 4.1 So if everyone uploaded perfect changesets we'd only need 40 core reviews per day :-) Though in practice it takes on average about 4 tries for Nova. Obviously some of those updated patchsets are due to automatic feedback from Jenkins and -1 could come from anyone, but in practice of course cores review a lot of patches in progress rather than just when they're ready. Though the more non-cores picking up issues, the less that needs to occur. Queue growth is a derived number which I think is correct as its based on new changes versus ones which merge or are abandoned (but I might be wrong). Its not necessarily a problem as long as the delay through the queue does not increase as the queue length is going to grow as a project becomes more active if the time taken to get through the queue remains the same. It also probably changes a bit depending on the exact time slice of the development period you look at. Chris
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
