<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 14 February 2014 17:57, Jay Dobies <span dir="ltr"><<a href="mailto:jason.dobies@redhat.com" target="_blank">jason.dobies@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am propably repeating much of what James already said already. But I think an<br>
operator that makes the decision to do a package base Triplo installation does<br>
so e.g. because he is familiar with the tools and conventions of the specific<br>
distro/provider of the packages he choose. And probably wants TripleO to be<br>
consistent with that. And yes, with the decision for packages, he decides to<br>
differ from the reference layout.<br>
</blockquote>
<br></div></div>
I agree with the notions that admins have come to expect differences from distro to distro. It's the case for any number of services.<br>
<br>
I'd go beyond that and say you're going to have problems getting the packages accepted/certified if they break the typical distro conventions. There are guidelines that say where things like Python code must live and packages may not even be accepted if they violate those.<br>

<br>
The same is likely for the admins themselves, taking issue if the packages don't match their expectation criteria for the distro.<div class="im HOEnZb"></div></blockquote></div><br></div><div class="gmail_extra">As a deployer, agreed. Distro's have their conventions and administrators get used to those conventions.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">As an alternative to trying to get distro packagers to conform to what you want, how about the part-way compromise of requesting that they at least symbolically lync the standard convention for the project... that way it's the best of both worlds.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Also, if a distro is going off the project standard then it really should be the responsibility of the distro parties to participate in the maintenance of the documentation. Obviously this can't be forced, but it can be encouraged.</div>
</div>