<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 9, 2016 at 11:54 AM, Hayes, Graham <span dir="ltr"><<a href="mailto:graham.hayes@hpe.com" target="_blank">graham.hayes@hpe.com</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"><br>
It might not make a difference to deployers / packagers who only deploy<br>
one project from OpenStack, but they are in the minority - having a<br>
known good minimum for requirements helps deployers who have multiple<br>
services to deploy.<br>
</blockquote><div><br></div><div>I'm not sure how true that is.  I think in the largest cloud organizations the different cloud services are managed by different teams that are working hard to deliver a stable, well tested, continuously deployed, *service* that is always rapidly approaching tracking master.</div><div><br></div><div>In these organizations it may be that the team ultimately fully responsible for the successful quality and availability of just a *single* service - doesn't need to *test* and deploy with the next new minor version of routes (if their requirements don't mandate it) just to get out the next bug fix - because they're not *trying* to co-install *all* the services onto a homogenous fleet?</div><div><br></div><div>Even if these kind of teams were let's say... a non-trivial minority... I don't think their needs should be *ignored*.  I agree with John & Thomas and am excited to hear about Tony's effort.</div><div><br></div><div> -Clay</div></div></div></div>