Open Stack

On Thu, May 22, 2014 at 9:05 AM, Dan Prince <dprince at redhat.com> wrote:

> ----- Original Message -----
> > From: "Devananda van der Veen" <devananda.vdv at gmail.com>>
> [...]
>
> interface. However, I also don't expect the author to provide a full
> > third-party CI environment, and as such, we should not claim the same
> level
> > of test coverage and consistency as we would like to have with drivers in
> > the gate.
>
> Not claiming the same level of support seems reasonable if we don't have
> 3rd party CI running on it.
>

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...


> > So, why not just put the driver in a separate library on github or
> > stackforge?
>
>  Because the driver can be easily broken due to internal Ironic driver API
> changes. :(
>

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.

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.

It would be great if we would adopt common nomenclature here so user
expectations are consistent:
* 'experimental' - stuff not tested at all?
* 'contrib' - stuff with some amount of testing short of gating
* 'thirdparty' - stuff that requires hardware or licensed software to fully
test

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.

Projects are going to do what they want regarding inclusion/exclusion
policies, I hope we can use common practices to implement those choices.

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140522/dbbeddc2/attachment.html>