Open Stack

On Thu, Aug 28, 2014 at 01:04:57AM +0000, Dugger, Donald D wrote:
> I'll try and not whine about my pet project but I do think there
> is a problem here.  For the Gantt project to split out the scheduler
> there is a crucial BP that needs to be implemented (
> https://review.openstack.org/#/c/89893/ ) and, unfortunately, the
> BP has been rejected and we'll have to try again for Kilo.  My question
> is did we do something wrong or is the process broken?
> 
> Note that we originally proposed the BP on 4/23/14, went through 10 
> iterations to the final version on 7/25/14 and the final version got
> three +1s and a +2 by 8/5.  Unfortunately, even after reaching out
> to specific people, we didn't get the second +2, hence the rejection.

I see at that it did not even get one +2 at the time of the feature
proposal approval freeze. You then successfully requested an exception
and after a couple more minor updates got a +2 from John but from no
one else.

I do think this shows a flaw in our (core teams) handling of the
blueprint. When we agreed upon the freeze exception, that should
have included a firm commitment for a least 2 core devs to review
it. IOW I think it is reasonable to say that either your feature
should have ended up with two +2s and +A, or you should have seen
a -1 from another core dev. I don't think it is acceptable that
after the exception was approved it only got feedback from one
core dev.   I actually thought that when approving exceptions, we
always got 2 cores to agree to review the item to avoid this, so
I'm not sure why we failed here.

> I understand that reviews are a burden and very hard but it seems
> wrong that a BP with multiple positive reviews and no negative
> reviews is dropped because of what looks like indifference.  Given
> that there is still time to review the actual code patches it seems
> like there should be a simpler way to get a BP approved.  Without
> an approved BP it's difficult to even start the coding process.
> 
> I see 2 possibilities here:
> 
> 
> 1)      This is an isolated case specific to this BP.  If so,
> there's no need to change the procedures but I would like to
> know what we should be doing differently.  We got a +2 review 
> on 8/4 and then silence for 3 weeks.
> 
> 2)      This is a process problem that other people encounter.
> Maybe there are times when silence means assent.  Something
> like a BP with multiple +1s and at least one +2 should
> automatically be accepted if no one reviews it 2 weeks after
> the +2 is given.

My two thoughts are

 - When we approve something for exception should actively monitor
   progress of review to ensure it gets the neccessary attention to
   either approve or reject it. It makes no sense to approve an
   exception and then let it lie silently waiting for weeks with no
   attention. I'd expect that any time exceptions are approved we
   should babysit them and actively review their status in the weekly
   meeting to ensure they are followed up on.

 - Core reviewers should prioritize reviews of things which already
   have a +2 on them. I wrote about this in the context of code reviews
   last week, but all my points apply equally to spec reviews I believe.

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

Also note that in Kilo the process will be slightly less heavyweight in
that we're going to try allow some features changes into tree without
first requiring a spec/blueprint to be written. I can't say offhand
whether this particular feature would have qualifying for the lighter
process, but in general by reducing need for specs for the more trivial
items, we'll have more time available for review of things which do
require specs.

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 :|