<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Oct 12, 2013 at 12:21 PM, Alessandro Pilotti <span dir="ltr"><<a href="mailto:apilotti@cloudbasesolutions.com" target="_blank">apilotti@cloudbasesolutions.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
On 12.10.2013, at 20:22, "Dan Smith" <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br>
<br>
>> From the user perspective, splitting off the projects seems to be<br>
>> focussing on the ease of commit compared to the final user<br>
>> experience.<br>
><br>
> I think what you describe is specifically the desire that originally<br>
> spawned the thread: making the merging of changes to the hyper-v driver<br>
> faster by having them not reviewed by the rest of the Nova team. It<br>
> seems to be what the hyper-v developers want, not necessarily what the<br>
> Nova team as a whole wants.<br>
><br>
>> An 'extras' project without *strong* testing co-ordination with<br>
>> packagers such as SUSE and RedHat would end up with the consumers of<br>
>> the product facing the integration problems rather than resolving<br>
>> where they should be, within the OpenStack project itself.<br>
><br>
> I don't think splitting out to -extras means that it loses strong<br>
> testing coordination (note that strong testing coordination does not<br>
> exist with the hyper-v driver at this point in time). Every patch to the<br>
> -extras tree could still be unit (and soon, integration) tested against<br>
> the current nova tree, using the proposed patch applied to the -extras<br>
> tree. It just means that a change against nova wouldn't trigger the<br>
> same, which is why the potential for "catch up" behavior would be required.<br>
><br>
>> I am sympathetic to the 'extra' drivers problem such as Hyper-V and<br>
>> powervm, but I do not feel the right solution is to split.<br>
>><br>
>> Assuming there is a summit session on how to address this, I can<br>
>> arrange a user representation in that session.<br>
><br>
> Cool, I really think we're at the point where we know the advantages and<br>
> disadvantages of the various options and further face-to-face discussion<br>
> at the summit is what is going to move us to the next stage.<br>
><br>
<br>
</div></div>I agree. Looks like we are converging towards a common ground. I'm summing it up here, including a few additional details, for the benefit of who will not join us in HK (sorry, we'll party for you as well :-)):<br>
</blockquote><div><br></div><div><br></div><div>This sounds like a very myopic solution to the issue you originally raised, and I don't think it will solve the underlying issues.</div><div><br></div><div><br></div><div>
<br></div><div>Taking a step back, you originally raised a concern about how we prioritize reviews with the havana-rc-potential tag.</div><div><br></div><div>"<span style="font-family:arial,sans-serif;font-size:13px">In the past weeks we diligently marked bugs that are related to Havana features with the "havana-rc-potential" tag, which at least for what Nova is concerned, had absolutely no effect.</span></div>
<div style="font-family:arial,sans-serif;font-size:13px">Our code is sitting in the review queue as usual and, not being tagged for a release or prioritised, there's no guarantee that anybody will take a look at the patches in time for the release. Needless to say, this starts to feel like a Kafka novel. :-)" [1]</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">If the issue is just better bug triage and prioritizing reviews, help us do that!</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">[2] shows the current status of your hyper-v havana-rc-potential bugs. Currently there are only 7 bugs that have both tags. Of those 7, 3 have no pending patches to trunk, and one doesn't sound like it warrants a back port (<a href="https://bugs.launchpad.net/nova/+bug/1220256" style="font-family:arial;font-size:small">https://bugs.launchpad.net/nova/+bug/1220256</a>).</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Looking at the remaining 4, one is marked as a WIP by you (<a href="https://bugs.launchpad.net/nova/+bug/1231911" style="font-family:arial;font-size:small">https://bugs.launchpad.net/nova/+bug/1231911</a> <a href="https://review.openstack.org/#/c/48645/" style="font-family:arial;font-size:small">https://review.openstack.org/#/c/48645/</a>) which leaves three patches for nova team to review. Three reviews open for a week doesn't sound like an issue that warrants a whole new repository.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">You went on to clarify your position.</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px"><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><snip></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." [3]</div>
<div><br></div><div><br></div><div>Once again you raise the issue of bug triage and prioritization of reviews (and blueprints), so help us fix that! This isn't a virt driver only issue though.</div><div><br></div><div>
The issues you originally raise are only incidentally related to virt drivers and hyper-v. The same issues can be brought up as you point out by any sub-project (scheduling, APIs, DB, etc). So a fix for only virt drivers hardly sounds like an appropriate solution.</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div>I would like t propose an alternate two part solution to the issues you originally raised.</div><div><br></div><div>* It sounds like nova needs to do a better job of bug triage, prioritizing reviews and blueprints. With so many bugs and reviews its very easy for us to mess this up. How to do a better job? I think we need to brainstorm on this a little.</div>
<div><br></div><div>* Do a better job of tracking how knowledgeable a reviewer is about a subset of code, just because someone is in core doesn't mean they know the most about a specific component. I think its safe to say that on average the more someone commits patches and reviews a file the more he knows about it. With git and gerrit we have all this information we just need to use it. Here is a quick proof of concept of the idea, (as a proof of concept it just lists previous authors of the modified files): <a href="https://gist.github.com/jogo/6955514">https://gist.github.com/jogo/6955514</a>, along with some sample outputs <a href="http://paste.openstack.org/show/48340/">http://paste.openstack.org/show/48340/</a>.</div>
<div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div><font face="arial, sans-serif">[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-October/016382.html">http://lists.openstack.org/pipermail/openstack-dev/2013-October/016382.html </a> </font><br>
</div><div><font face="arial, sans-serif">[2] </font><a href="https://bugs.launchpad.net/nova/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=havana-rc-potential+hyper-v+&field.tags_combinator=ALL&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on" style="font-family:arial,sans-serif;font-size:13px">https://bugs.launchpad.net/nova/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=havana-rc-potential+hyper-v+&field.tags_combinator=ALL&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on</a></div>
<div>[3] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-October/016400.html">http://lists.openstack.org/pipermail/openstack-dev/2013-October/016400.html</a><font face="arial, sans-serif"><br></font></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
1) All the drivers will still be part of Nova.<br>
<br>
2) One official project (nova-drivers-incubator?) or more than one will be created for the purpose of supporting a leaner and faster development pace of the drivers.<br>
<br>
3) Current driver sub-project teams will informally elect their maintainer(s) which will have +2a rights on the new project or specific subtrees.<br>
<br>
4) Periodically, code from the new project(s) must be merged into Nova.<br>
Only Nova core reviewers will have obviously +2a rights here.<br>
I propose to do it on scheduled days before every milestone, differentiated per driver to distribute the review effort (what about also having Nova core reviewers assigned to each driver? Dan was suggesting something similar some time ago).<br>
<br>
5) All drivers will be treated equally and new features and bug fixes for master (except security ones) should land in the new project before moving to Nova.<br>
<br>
6) CI gates for all drivers, once available, will be added to the new project as well. Only drivers code with a CI gate will be merged in Nova (starting with the Icehouse release as we already discussed).<br>
<br>
7) Active communication should be maintained between the Nova core team and the drivers maintainers. This means something more than: "I wrote it on the ML didn't you see it?" :-)<br>
<br>
A couple if questions: will we keep version branches on the new project or just master?<br>
<br>
Bug fixes for older releases will be proposed to the incubator for the current release in development and to Nova for past versions branches?<br>
<br>
Please correct me if I missed something!<br>
<br>
Thanks,<br>
<br>
Alessandro<br>
<div class=""><div class="h5"><br>
> --Dan<br>
><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>
_______________________________________________<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>