<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br class="Apple-interchange-newline">
</div>
</span><br class="Apple-interchange-newline">
</span><br class="Apple-interchange-newline">
</div>
<br>
<div>
<div>On Oct 10, 2013, at 23:50 , Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>></div>
<div> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">On 10/10/2013 02:20 PM, Alessandro Pilotti wrote:<br>
<blockquote type="cite">Hi all,<br>
<br>
As the Havana release date is approaching fast, I'm sending this email<br>
to sum up the situation for pending bugs and reviews related to the<br>
Hyper-V integration in OpenStack.<br>
<br>
In the past weeks we diligently marked bugs that are related to Havana<br>
features with the "havana-rc-potential" tag, which at least for what<br>
Nova is concerned, had absolutely no effect.<br>
Our code is sitting in the review queue as usual and, not being tagged<br>
for a release or prioritised, there's no guarantee that anybody will<br>
take a look at the patches in time for the release. Needless to say,<br>
this starts to feel like a Kafka novel. :-)<br>
The goal for us is to make sure that our efforts are directed to the<br>
main project tree, avoiding the need to focus on a separate fork with<br>
more advanced features and updated code, even if this means slowing down<br>
a lot our pace. Due to the limited review bandwidth available in Nova we<br>
had to postpone to Icehouse blueprints which were already implemented<br>
for Havana, which is fine, but we definitely cannot leave bug fixes<br>
behind (even if they are just a small number, like in this case).<br>
<br>
Some of those bugs are critical for Hyper-V support in Havana, while the<br>
related fixes typically consist in small patches with very few line changes.<br>
</blockquote>
<br>
Does the rant make you feel better? :-)<br>
<br>
</blockquote>
<div><br>
</div>
<div>Hi Russell, </div>
<div><br>
</div>
<div>This was definitely not meant to sound like a rant, I apologise if you felt it that way. :-)</div>
<div><br>
</div>
<blockquote type="cite">With a more general view of nova review performance, our averages are<br>
very good right now and are meeting our goals for review turnaround times:<br>
<br>
</blockquote>
<blockquote type="cite"><a href="http://russellbryant.net/openstack-stats/nova-openreviews.html">http://russellbryant.net/openstack-stats/nova-openreviews.html</a><br>
<br>
--> Total Open Reviews: 230<br>
--> Waiting on Submitter: 105<br>
--> Waiting on Reviewer: 125<br>
<br>
--> Stats since the latest revision:<br>
----> Average wait time: 3 days, 12 hours, 14 minutes<br>
----> Median wait time: 1 days, 12 hours, 31 minutes<br>
----> Number waiting more than 7 days: 19<br>
<br>
--> Stats since the last revision without -1 or -2 (ignoring jenkins):<br>
----> Average wait time: 5 days, 10 hours, 57 minutes<br>
----> Median wait time: 2 days, 13 hours, 27 minutes<br>
<br>
</blockquote>
<br>
<div>
<div>Usually when this type of discussion comes up, the first answer that I hear is some defensive data about how well project X ranks compared to some metric or the whole OpenStack average.</div>
<div>I'm not putting into discussion how much and well you guys are working (I actually firmly believe that you DO work very well), I'm just discussing about the way in which blueprints and bugs get prioritised.</div>
<div><br>
</div>
<div>Working on areas like Hyper-V inside of the OpenStack ecosystem is currently quite peculiar from a project management perspective due to the fragmentation of the commits among a number of larger projects.</div>
<div>Our bits are spread allover between Nova, Neutron, Cinder, Ceilometer, Windows Cloud-Init and let's not forget Crowbar and OpenVSwitch, although not stricly part of OpenStack. Except obviously Windows Cloud-Init, in none of those projects our contribution
reaches the critical mass required for the project to be somehow dependent on what we do and reach a "core" status that would generate a sufficient autonomy. Furthermore, to complicate things more, with every release we are adding features to more projects.</div>
<div><br>
</div>
<div>On the other side, to get our code reviewed and merged we are always dependent on the good will and best effort of core reviewers that don't necessarily know or care about specific driver, plugin or agent internals. This brings to even longer review cycles
even considering that reviewers are clearly doing their best in understanding the patches and we couldn't be more thankful. </div>
<div><br>
</div>
<div>"Best effort" has also a very specific meaning: in Nova all the Havana Hyper-V blueprints were marked as "low priority" (which can be translated in: "the only way to get them merged is to beg for reviews or maybe commit them on day 1 of the release cycle
and pray") while most of the Hyper-V bugs had no priority at all (which can be translated in "make some noise on the ML and IRC or nobody will care"). :-) </div>
<div><br>
</div>
<div>This reality unfortunately applies to most of the sub-projects (non only Hyper-V) and can be IMHO solved only by delegating more authonomy to the sub-project teams on their specific area of competence across OpenStack as a whole. Hopefully we'll manage
to find a solution during the design summit as we are definitely not the only ones feeling this way, by judging on various threads in this ML.</div>
<div><br>
</div>
<div>
<div>I personally consider that in a large project like this one there are multiple ways to work towards the achievement of the "greater good". Our call obviously consists in bringing OpenStack to the Microsoft world, which so far worked very well, I'd just
prefer to be able to dedicate more resources on adding features, fixing bugs and make users happy instead of useless waits.</div>
<div><br>
</div>
</div>
</div>
<blockquote type="cite">Also note that there are no hyper-v patches that are in the top 5 of any<br>
of the lists of patches waiting the longest. So, you are certainly not<br>
being singled out here.<br>
</blockquote>
<div><br>
</div>
<div>Please note that I never said that. Some people might say that in Nova "All hypervisors are equal but some are more equal than others", but this is not my point of view :-) </div>
<br>
<blockquote type="cite"><br>
Please understand that I only want to help here. Perhaps a good way for<br>
you to get more review attention is get more karma in the dev community<br>
by helping review other patches. It looks like you don't really review<br>
anything outside of your own stuff, or patches that touch hyper-v. In<br>
the absence of significant interest in hyper-v from others, the only way<br>
to get more attention is by increasing your karma.<br>
<br>
</blockquote>
<div><br>
</div>
<div>Frankly, the way you put it, you make sound karma more like a "do ut des" contract. Anyway, those are not only "my patches", and while I coded most of them until Grizzly for lack of other experienced devs in the domain, now I'm handing over the baton to
an increasing number of community members, which are expert on the multiple aspects of the Hyper-V and Windows domains without necessarily being confident on every single area of Nova, Cinder, Neutron, Ceilometer, Tempest and so on.</div>
<div><br>
</div>
<div>So when you say that "It looks like you don't really review anything outside of your own stuff, or patches that touch hyper-v" (where my own stuff I guess means Hyper-V related patches by other people) it is obviously true! </div>
<div>The fact that you see only the subset of the reviews that I'm doing in Nova and not the rest of the review work, does not mean that I don't do reviews!</div>
<div><br>
</div>
<div>Our domain is the area in which me and my sub-team can add the biggest value. Being also an independent startup, we reached now the stage in which we can sponsor some devs to do reviews all the time outside of our core domain, but this will take a few
months spawning one or two releases as aquiring the necessary understanding of a project like e.g. Nova cannot be done overnight.</div>
<div><br>
</div>
<div>I hope that this email appears clearly constructive and that you'll not take it as a rant, it is pretty far from being one. :-)</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Alessandro</div>
<div><br>
</div>
<br>
<blockquote type="cite"><a href="https://review.openstack.org/#/q/reviewer:3185+project:openstack/nova,n,z">https://review.openstack.org/#/q/reviewer:3185+project:openstack/nova,n,z</a><br>
<br>
-- <br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</div>
<br>
</body>
</html>