<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 15, 2014 at 3:01 PM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.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 dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div class="">On Thu, Aug 14, 2014 at 4:02 PM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.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><br>
> > Additional cross-project resources can be ponied up by the large<br>
> > contributor companies, and existing cross-project resources are not<br>
> > necessarily divertable on command.<br>
><br>
> Sure additional cross-project resources can and need to be ponied up, but I<br>
> am doubtful that will be enough.<br>
<br>
</div>OK, so what exactly do you suspect wouldn't be enough, for what<br>
exactly?<br>
<br></blockquote><div><br></div></div><div>I am not sure what would be enough to get OpenStack back in a position where more developers/users are happier with the current state of affairs. Which is why I think we may want to try several things.</div>
<div class="">
<div><br></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">
Is it the likely number of such new resources, or the level of domain-<br>
expertise that they can be realistically be expected bring to the<br>
table, or the period of time to on-board them, or something else?<br><br></blockquote><div><br></div></div><div>Yes, all of the above.</div><div class=""><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">
And which cross-project concern do you think is most strained by the<br>
current set of projects in the integrated release? Is it:<br>
<br>
* QA<br>
* infra<br>
* release management<br>
* oslo<br>
* documentation<br>
* stable-maint<br>
<br>
or something else?<br>
<br></blockquote><div><br></div></div><div>Good question.</div><div><br></div><div>IMHO QA, Infra and release management are probably the most strained. But I also think there is something missing from this list. Many of the projects are hitting similar issues and end up solving them in different ways, which just leads to more confusion for the end user. Today we have a decent model for rolling out cross-project libraries (Oslo) but we don't have a good way of having broader cross project discussions such as: API standards (such as discoverability of features), logging standards, aligning on concepts (different projects have different terms and concepts for scaling and isolating failure domains), and an overall better user experience. So I think we have a whole class of cross project issues that we have not even begun addressing.</div>
</div></div></div></blockquote><div><br></div><div>Docs are very, very strained. We scope docs to integrated only and we're still lacking in quality, completeness, and speed of reviews.</div><div><br></div><div><div>
At this week's extra TC meeting [1] we discussed only the difficulties with integration and growth. I also want us to think about the cost of integration with the current definitions and metrics we have. We discussed whether the difficulties lie in the sheer number of projects, or is the difficulty in the complexity due to cross-integration? </div>
<div><br></div><div>For docs I can point to "sheer number of projects" which is why we scope to integrated only. But even that definition is becoming difficult for cross-project so I want to explore the cross-project implications before the "sheer number" implications. </div>
<div><br></div><div>One of the metrics I'd like to see is <span style="color:rgb(0,0,0);white-space:pre-wrap">a metric of "most cross-project drag" for all programs. The measures might be:</span></div><div>
<span style="color:rgb(0,0,0);white-space:pre-wrap">- number of infrastructure nodes used to test</span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap">- number of infrastructure jobs needed</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">- most failing tests</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">- incompleteness of test suite</span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap">- incompleteness of docs</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">- difficulty for users to use (API, CLI, or configuration) due to lack of docs or hard-to-understand complexities</span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap">- most bugs affecting more than one project (cross-project bugs would count against both projects)</span></div><div>- performance in production environments due to interlocking project needs</div>
<div>- any others? <br></div><div><br></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">We know nova/neutron carries a lot of this integration drag. We know there's not an "easy button" -- but should we focus on the hard problems before integrating many more projects? For now I think our answer is no, but I want to hear what others think about that consideration as an additional metric before moving projects through our incubator. </span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Thanks,</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Anne</span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">1. </span><font color="#000000"><span style="white-space:pre-wrap"><a href="http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-08-14-19.03.log.html">http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-08-14-19.03.log.html</a></span></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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="">
<div><br></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">
Each of those teams has quite different prerequisite skill-sets, and<br>
the on-ramp for someone jumping in seeking to make a positive impact<br>
will vary from team to team.<br>
<br>
Different approaches have been tried on different teams, ranging from<br>
dedicated project-liaisons (Oslo) to shared cores (Sahara/Infra) to<br>
newly assigned dedicated resources (QA/Infra). Which of these models<br>
might work in your opinion? Which are doomed to failure, and why?<br>
<br>
So can you be more specific here on why you think adding more cross-<br>
project resources won't be enough to address an identified shortage<br>
of cross-project resources, while de-integrating projects would be?<br>
<br>
And, please, can we put the proverbial strawman back in its box on<br>
this thread? It's all well and good as a polemic device, but doesn't<br>
really move the discussion forward in a constructive way, IMO.<br>
<br>
Thanks,<br>
<div><div>Eoghan<br>
<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><br></div></div>