On 10 June 2014 17:53, Mark McLoughlin <mar...@redhat.com> wrote: > On Tue, 2014-06-10 at 16:09 +0100, Duncan Thomas wrote: >> On 10 June 2014 15:07, Mark McLoughlin <mar...@redhat.com> wrote: >> >> > Exposing which configurations are actively "tested" is a perfectly sane >> > thing to do. I don't see why you think calling this "certification" is >> > necessary to achieve your goals. >> >> What is certification except a formal way of saying 'we tested it'? At >> least when you test it enough to have some degree of confidence in >> your testing. >> >> That's *exactly* what certification means. > > I disagree. I think the word has substantially more connotations than > simply "this has been tested". > > http://lists.openstack.org/pipermail/openstack-dev/2014-June/036963.html
Ok, so I think you have a high opinion of certification programs in general than my experiences have led me to expect, but I'm starting to see your point. <snip> >> Since cinder, >> and therefore cinder-core, is going to get the blame, I feel we should >> try to maintain some degree of control over the claims. > > I'm starting to see where you're coming from, but I fear this > "certification" thing will make it even worse. > > Right now you can easily shrug off any responsibility for the quality of > a third party driver or an untested in-tree driver. Sure, some people > may have unreasonable expectations about such things, but you can't stop > people being idiots. You can better communicate expectations, though, > and that's excellent. > > But as soon as you "certify" that driver cinder-core takes on a > responsibility that I would think is unreasonable even if the driver was > tested. "But you said it's certified!" > > Is cinder-core really ready to take on responsibility for every issue > users see with "certified" drivers and downstream OpenStack products? I think we de facto have a lot of that responsibility, whether we like it or not. You might be right about the work certification making it worse, I don't think it does, but at least I'm managed to explain my position clearly and I think it has been understood. > If it's an out-of-tree driver then we say "talk to your vendor". > > If it's an in-tree driver, those actively maintaining the driver provide > "best effort community support" like anything else. > > If it's an in-tree driver and isn't being actively maintained, and "best > effort community support" isn't being provided, then we need a way to > communicate that unmaintained status. The level of testing it receives > is what we currently see as the most important aspect, but it's not the > only aspect. In cinder, I expect a driver removal patch to be the communication method. I think that view (with varying degrees of communication, carrot and stick before hand to get a better resolution if possible) is pretty much agreed by most of cinder core. > Mark. Thanks for your time and repeated replies, I think we are now both aware of what the other person is saying and why, which is the point I wanted to get to. It seems like the weight of opinion is against me, so I'll go quiet on the subject... it is in the end a subjective matter. Thanks to Anita for opening the discussion. -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev