<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 20, 2016 at 7:48 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">The other approach is product-centric: "lower-level pieces are OpenStack dependencies, rather than OpenStack itself". If we are missing a lower-level piece to achieve our mission and are developing it as a result, it could be developed on OpenStack infrastructure by members of the OpenStack community but it is not "OpenStack the product", it's an OpenStack *dependency*. It is not governed by the TC, it can use any language and tool deemed necessary.<br></blockquote><div><br></div><div>I think we should include the degree of OpenStack-specificness here, as something that may fit every other of your criteria for 'used by but not part of OpenStack' is really only useful to OpenStack (Designate's DNS code, for example, apparently reads the DB) should be part of OpenStack.  IIRC that has been used as one of the criteria for deciding if a new library should be part of Oslo or stand-alone (independent of in-or-out of OpenStack governance).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">That is what I mean by 'scope': where does "OpenStack" stop, and where do "OpenStack dependencies" start ? It is a lot easier and a lot less community-costly to allow additional languages in OpenStack dependencies (we already have plenty there).</blockquote><div><br></div><div>So down the road when one of these dependencies that is very important to OpenStack goes more dormant than we would like due to resource allocation issues because it is not-Big Tent, will we adopt it like we have done with other dependencies where that made more sense than re-writing around it?</div></div><div><br></div><div>I do hope that should the TC adopt the position of drawing the scope line tighter around the core, that the tent-cleaning will follow in both directions, down toward kernel-space and up toward end-user-space.  We are historically bad at leaving that sort of debt lying and cleaning can make some strides toward reducing the community cost of maintaining the current ecosystem.</div><div><br></div><div>dt</div><div><br></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>