Open Stack

On Tue, Aug 19, 2014 at 8:47 AM, Daniel P. Berrange <berrange at redhat.com>
wrote:

> On Tue, Aug 19, 2014 at 09:31:48PM +1200, Robert Collins wrote:
> > Hey everybody - https://wiki.openstack.org/wiki/TripleO/SpecReviews
> > seems pretty sane as we discussed at the last TripleO IRC meeting.
> >
> > I'd like to propose that we adopt it with the following tweak:
> >
> > 19:46:34 <lifeless> so I propose that +2 on a spec is a commitment to
> > review it over-and-above the core review responsibilities
> > 19:47:05 <lifeless> if its not important enough for a reviewer to do
> > that thats a pretty strong signal
> > 19:47:06 <dprince> lifeless: +1, I thought we already agreed to that
> > at the meetup
> > 19:47:17 <slagle> yea, sounds fine to me
> > 19:47:20 <bnemec> +1
> > 19:47:30 <lifeless> dprince: it wasn't clear whether it was
> > part-of-responsibility, or additive, I'm proposing we make it clearly
> > additive
> > 19:47:52 <lifeless> and separately I think we need to make surfacing
> > reviews-for-themes a lot better
> >
> > That is - +1 on a spec review is 'sure, I like it', +2 is specifically
> > "I will review this *over and above* my core commitment" - the goal
> > here is to have some very gentle choke on concurrent WIP without
> > needing the transition to a managed pull workflow that Nova are
> > discussing - which we didn't have much support for during the meeting.
>
> If it is considered to be a firm commitment to review the code, then
> people will have to be quite conservative when approving blueprints
> lest take accept too much work. It is hard to predict just how much
> work will be involved in the code review from the spec though, and
> even harder to predict /when/ during the dev cycle the code will be
> posted.
>
> I could approve 10 specs and think that's reasonable for the dev
> cycle, but if those 10 all have their code posted in Kilo-3, then
> I could be sitting idle with no features to review during Kilo-1/2
> - time that could have been filled with specs I chose not to approve.
> And similarly I can still end up with far too much work during the
> Kilo3 phase to review.
>

>From the wiki:


   - There should be a sufficient number of core reviewers who have
   volunteered to go *above and beyond* their typical reviewer workload
   (indicated by their +2) to review the relevant patches. A "sufficient
   number" is dependent on the individual spec and the scope of the change.
   - If reviewers have said they'll be reviewing a spec's patches *instead* of
   patches they'd review otherwise, that doesn't help much and is actually
   harmful to the overall project.


So if the 10 specs you +2ed, don't have code posted until late, you should
*not* be sitting idle, you should be doing regular code reviews for
non-blueprints.


While I cannot speak for the dynamics of the tripleo team, if this were to
be adopted in nova I would not +2 any blueprints as I don't think I can
commit to *guaranteeing* I will have even more review bandwidth, I can make
best efforts but a personally cannot guarantee.


>
> In terms of my efficiency as a reviewer it is really in my interests
> to approve more work than I can reasonably expect to review, and then
> prioritize the review activity at time stuff appears for review. Some
> stuff that's approved will ultimately miss out, but I think that is
> perfectly acceptable. People can improve their chances of not missing
> out by getting their code up for review sooner than their competitors
> which is a useful carrot IMHO.
>
>
> 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
> :|
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140819/43ddb050/attachment.html>