On Tue, Aug 19, 2014 at 8:47 AM, Daniel P. Berrange <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
