<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2019 at 11:24 PM Eric Fried <openstack@fried.cc> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I'm pretty sure Jay wasn't doing 60% of the reviews in Nova<br>
<br>
Clearly not what I was implying.<br>
<br>
> splitting out placement was supposed to *reduce* the load on the nova<br>
> core team?<br>
<br>
In a sense, that's exactly what I'm suggesting - but it took a couple<br>
releases (those releases) to get there. Both the effort to do the<br>
extraction and the overlap between the placement and nova teams during<br>
that time frame pulled resource away from nova itself.<br>
<br>
> If anything that was a time sink that is now finished,<br>
> placement is off soaring on its own merits and we have a bunch of<br>
> resource back as a result, no?<br>
<br>
Okay, I can buy that. Care to put a number on it?<br>
<br>
> How about approved specs require a majority (or some larger-than-two<br>
> number) of the cores to +2 it to indicate "yes we should do this, and<br>
> yes we should do it this cycle"? Some might argue that this unfairly<br>
> weight efforts that have a lot of cores interested in seeing them land,<br>
> instead of the actual requisite two, but it sounds like that's what<br>
> you're shooting for?<br>
<br>
I think the "core sponsor" thing will have this effect: if you can't get<br>
a core to sponsor your blueprint, it's a signal that "we" don't think it<br>
should be done (this cycle).<br>
<br>
I like the >2-core idea, though the real difference would be asking for<br>
cores to consider "should we do this *in this cycle*" when they +2 a<br>
spec. Which is good and valid, but (I think) difficult to<br>
explain/track/quantify/validate. And it's asking each core to have some<br>
sense of the "big picture" (understand the scope of all/most of the<br>
candidates) which is very difficult.<br>
<br>
> since we've expanded the entire core team to be able to approve specs,<br>
> people that are +2 on a spec should be expected to be willing to help in<br>
> reviewing the resulting blueprint code that comes out of it, but that<br>
> doesn't always happen.<br>
<br>
Agree. I considered trying to enforce that spec and/or blueprint<br>
approvers are implicitly signing up to "care about" those<br>
specs/blueprints, but I assumed that would result in a drastic reduction<br>
in willingness to be an approver :P<br>
<br></blockquote><div><br></div><div>Actually, that sounds a very reasonable suggestion from Matt.</div><div>If you do care reviewing a spec, that also means you do care reviewing the implementation side.</div><div>Of course, things can happen meanwhile and you can be dragged on "other stuff" (claim what you want) so you won't have time to commit on the implementation review ASAP, but your interest is still fully there.</div><div>On other ways, it's a reasonable assumption to consider that cores approving a spec somehow have the responsibility to move forward with the implementation and can consequently be gently pinged for begging reviews.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Which I suppose would serve to reduce the number of approved blueprints<br>
in the cycle... Hm....<br>
<br></blockquote><div><br></div><div>That's just the reflect of the reality IMHO.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
efried<br>
.<br>
<br>
</blockquote></div></div>