openstack team mailing list archive

[Eoghan Glynn <eglynn@xxxxxxxxxx>]

> There's something like 7 pages of open reviews on gerrit.  The project
> has a good kind of problem with so many people trying to contribute.
> The question now is how to scale the development processes to handle
> that growth.
> 
> It was nice to see a number of discussions at the summit in this area.
> The biggest backlog is nova, and there are discussions of both splitting
> parts out to make nova smaller, as well as adopting feature branches and
> merge windows.  The feature branches could have more reviewers that are
> experts in that area, but not necessarily nova-core.  Hopefully these
> things will help in the Folsom cycle.
> 
> Thanks to all of the core reviewers who regularly invest time into
> reviewing submissions!  :-)


Some simple processes that I've seen improve matters on seemingly
unmanagable backlogs:

1. An initial short & concerted queue draining exercise (e.g. a
   review-busting day where all core team members agree to dedicate
   a significant portion of their openstack time to reviews).

   The intended outcome is a much leaner queue as a starting point
   (at the cost of potential instability with many more patches 
   landing on master than would normally be the case, so it makes
   sense to do this early in the release cycle). 

2. Prominent visibility to a number of simple stats that capture the
   trend on responsiveness:

   - age of the oldest unreviewed patch
   - average turnaround time from submission to merge or -2
   - number of open unreviewed patches
   - number of reviewed patches needing approval
 
   There would an implicit goal not to leave the stats in worse shape
   than yesterday at the end of each core-team members' rostered review
   day.

3. A "loose" SLA indicating the level of responsiveness that patch
   submitters can expect, e.g. "we strive to respond within X working
   days, average turnaround time is currently Y days".

4. If things get out of hand again GOTO #1.