<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 7:33 AM, Anne Gentle <span dir="ltr"><<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">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>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><font color="#888888"><br></font></span></blockquote><div><br></div></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 class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888">
--<br>
Russell Bryant<br>
</font></span><div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div><br></div></div>
<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>
<br></blockquote></div><div class="gmail_default" style="font-family:'courier new',monospace">Seems everybody that's been around a while has noticed "issues" this release and have talked about it, thanks Thierry for putting it together so well and kicking off the ML thread here.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">I'd agree with everything that you stated, I've also floated the idea this past week with a few members of the Core Cinder team to have an "every other" release for new drivers submissions in Cinder (I'm expecting this to be a HUGELY popular proposal [note sarcastic tone]). </div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">There are three things that have just crushed productivity and motivation in Cinder this release (IMO):</div>
<div class="gmail_default" style="font-family:'courier new',monospace">1. Overwhelming number of drivers (tactical contributions)</div><div class="gmail_default" style="font-family:'courier new',monospace">
2. Overwhelming amount of churn, literally hundreds of little changes to modify docstrings, comments etc but no real improvements to code</div><div class="gmail_default" style="font-family:'courier new',monospace">
3. A new sense of pride in hitting the -1 button on reviews. A large number of reviews these days seem to be -1 due to punctuation or misspelling in comments and docstrings. There's also a lot of "my way of writing this method is better because it's *clever*" taking place.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">In Cinder's case I don't think new features is a problem, in fact we can't seem to get new features worked on and released because of all the other distractions. That being said doing a maintenance or hardening only type of release is for sure good with me.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Anyway, I've had some plans to talk about how we might fix some of this in Cinder at next week's sprint. If there's a broader community effort along these lines that's even better.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Thanks,</div><div class="gmail_default" style="font-family:'courier new',monospace">
John</div><div class="gmail_default" style="font-family:'courier new',monospace"> </div><br></div></div>