<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 8:20 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is<br>
<div class="">slot selection would just be Nova drivers. I<br>
> think there is an assumption in the old system that everyone in Nova<br>
> core wants to prioritize the blueprints. I think there are a bunch of<br>
> folks in Nova core that are happy having signaling from Nova drivers on<br>
> high priority things to review. (I know I'm in that camp.)<br>
><br>
> Lacking that we all have picking algorithms to hack away at the 500 open<br>
> reviews. Which basically means it's a giant random queue.<br>
><br>
> Having a few blueprints that *everyone* is looking at also has the<br>
> advantage that the context for the bits in question will tend to be<br>
> loaded into multiple people's heads at the same time, so is something<br>
> that's discussable.<br>
><br>
> Will it fix the issue, not sure, but it's an idea.<br>
<br>
</div>OK, got it.  So, success critically depends on nova-core being willing<br>
to take review direction and priority setting from nova-drivers.  That<br>
sort of assumption is part of why I think agile processes typically<br>
don't work in open source.  We don't have the ability to direct people<br>
with consistent and reliable results.<br>
<br>
I'm afraid if people doing the review are not directly involved in at<br>
least ACKing the selection and commiting to review something, putting<br>
stuff in slots seems futile.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>My original thinking was I'd set aside a "meeting time" to review specs especially for doc issues and API designs. What I found quickly was that the 400+ queue in one project alone was not only daunting but felt like I wasn't going to make a dent as a single person, try as I may.</div>

<div><br></div><div>I did my best but would appreciate any change in process to help with prioritization. I'm pretty sure it will help someone like me, looking at cross-project queues of specs, to know what to review first, second, third, and what to circle back on. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
--<br>
Russell Bryant<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>