<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 22, 2014 at 9:05 AM, Dan Prince <span dir="ltr"><<a href="mailto:dprince@redhat.com" target="_blank">dprince@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="">----- Original Message -----<br>
> From: "Devananda van der Veen" <<a href="mailto:devananda.vdv@gmail.com">devananda.vdv@gmail.com</a>>><br></div><div class="">[...] </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">> interface. However, I also don't expect the author to provide a full<br>
> third-party CI environment, and as such, we should not claim the same level<br>
> of test coverage and consistency as we would like to have with drivers in<br>
> the gate.<br></div>
<br>
Not claiming the same level of support seems reasonable if we don't have 3rd party CI running on it.<br></blockquote><div><br></div><div>As was repeated many times last week:  "if it isn't tested it is broken".  We get to argue over the definition and degree of 'tested' now...</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> So, why not just put the driver in a separate library on github or<br>
> stackforge?<br>
<br>
</div> Because the driver can be easily broken due to internal Ironic driver API changes. :(<br>
</blockquote><div><br></div></div><div>I have similar issues with DevStack and including in-repo support for drivers/projects that are not integrated or incubated or even an OpenStack-affiliated project at all.  And have come to the conclusion that at some point some things just make sense to include anyway.  But the different status needs to be communicated somehow.</div>
<div><br></div><div>As a user of an open source project it is frustrating for me to want/need to use something in a 'contrib' directory and not be able to know if that thing still works or if it is even maintained.  Having a certain amount of testing to at least demonstrate non-brokenness should be a requirement for inclusion.</div>
<div><br></div><div>It would be great if we would adopt common nomenclature here so user expectations are consistent:</div><div>* 'experimental' - stuff not tested at all?</div><div>* 'contrib' - stuff with some amount of testing short of gating</div>
<div>* 'thirdparty' - stuff that requires hardware or licensed software to fully test</div><div><br></div><div>Also, contact information should be required for anything 'special' to at least know who to notify if the thing is so broken that removal is contemplated.</div>
<div><br></div><div>Projects are going to do what they want regarding inclusion/exclusion policies, I hope we can use common practices to implement those choices.</div><div><br></div><div>dt</div><div><br></div>-- <br><br>
Dean Troyer<br><a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
</div></div>