<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 1 December 2015 at 02:40, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Armando M. wrote:<br>
> [...]<br>
<span class="">> So my question is: would revisiting/clarifying the concept be due after<br>
> some time we have seen it in action? I would like to think so.<br>
<br>
</span>I also think it's time to revisit this experience now that it's been<br>
around for some time. On one hand the Neutron stadium allowed to<br>
increase the development bandwidth by tackling bottlenecks in reviews<br>
using smaller core review teams. On the other it's been difficult for<br>
Neutron leadership to follow up on all those initiatives and the results<br>
in terms of QA and alignment with "the OpenStack way" have been... mixed.<br>
<br>
And this touches on the governance issue. By adding all those projects<br>
under your own project team, you bypass the Technical Committee approval<br>
that they behave like OpenStack projects and are produced by the<br>
OpenStack community. The Neutron team basically vouches for all of them<br>
to be on par. As far as the Technical Committee goes, they are all being<br>
produced by the same team we originally blessed (the Neutron project team).<br>
<br>
That is perfectly fine with me, as long as the Neutron team feels<br>
confident they can oversee every single one of them and vouch for every<br>
single one of them. If the Neutron PTL feels the core Neutron leadership<br>
just can't keep up, I think we have a problem we need to address, before<br>
it taints the Neutron project team itself.<br>
<br>
One solution is, like you mentioned, to make some (or all) of them<br>
full-fledged project teams. Be aware that this means the TC would judge<br>
those new project teams individually and might reject them if we feel<br>
the requirements are not met. We might want to clarify what happens then.<br></blockquote><div><br></div><div>That's a good point. Do we have existing examples of this or would we be sailing in uncharted waters? That said, I didn't see you comment on the possible introduction of neutron-relevant tags, is something that the TC would be open to?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks for raising this thread!<br></blockquote><div><br></div><div>Thank you for chiming in!</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>
--<br>
Thierry Carrez (ttx)<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>