Open Stack

On Thu, Aug 28, 2014 at 04:27:59PM -0600, Chris Friesen wrote:
> On 08/28/2014 04:01 PM, Joe Gordon wrote:
> >
> >
> >
> >On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh
> ><alan.kavanagh at ericsson.com <mailto:alan.kavanagh at ericsson.com>> wrote:
> >
> >    I share Donald's points here, I believe what would help is to
> >    clearly describe in the Wiki the process and workflow for the BP
> >    approval process and build in this process how to deal with
> >    discrepancies/disagreements and build timeframes for each stage and
> >    process of appeal etc.
> >    The current process would benefit from some fine tuning and helping
> >    to build safe guards and time limits/deadlines so folks can expect
> >    responses within a reasonable time and not be left waiting in the cold.
> >
> >
> >This is a resource problem, the nova team simply does not have enough
> >people doing enough reviews to make this possible.
> 
> All the more reason to make it obvious which reviews are not being addressed
> in a timely fashion.  (I'm thinking something akin to the order screen at a
> fast food restaurant that starts blinking in red and beeping if an order
> hasn't been filled in a certain amount of time.)

This information can easily be queried from gerrit. I proposed last week that
core team members should especially look for reviews which have one +2 already,
as being items that are potentially approvable and thus should not be left to
lie idle for a long time

  http://lists.openstack.org/pipermail/openstack-dev/2014-August/043657.html

There are a variety of other ways/criteria to query lists of changes which
I outline with the gerrymander tool

  http://lists.openstack.org/pipermail/openstack-dev/2014-August/043085.html

> Perhaps by making it clear that reviews are a bottleneck this will actually
> help to address the problem.

We have the tools / capabilities for this already. The problems are whether
people effectively use the tools to priortize their work, and whether we
even have enough review bandwidth at all.

I'm certain though that this schedular review should not have got lost
in the way it did.

I'd like to see the core team set a firm target that a review with one +2
and no -1s, should not be allowed to languish for more than 1 week, with
out having either a second +2 or a -1 (unless it is blocked by a change
it depends on).

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|