Open Stack

On Thu, Nov 14, 2013 at 5:59 PM, Robert Collins
<robertc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/ff3aec04/attachment.html>