>    Of course the 3.0 release is kind of special because we are defining a
    completely new API - the providers API - with the intention to have it
    stable for many years to come. Any bugs in the API design for providers
    will have to live with us at least until the 4.0 release and so it is
    reasonable goal to avoid them if at all possible.

There's two parts to this, bugs within the API, and errors in the API 
definition itself.  You're talking about the latter, which is the more 
important thing.

Nowhere in this thread, or elsewhere, has there been any mention of how to test 
that the provider API is correct.  We have the existence proof of OpenSSL, but 
that's it. There are beliefs that it works, concerns about things missing, but 
no other running code.  If the provider API is paramount, then perhaps 
additional proof-points are needed?

>    Unfortunately the release requirements as defined in the proposal for
    OTC vote come fairly naturally from the feature requirements set by OMC

Where can I find those?  If they were posted I missed it.  If it's the 3.0 
design document [1] then, for example, I would say that the deprecation 
requirements are met because it doesn't mandate "remove from the code" style of 
deprecation.  But maybe there is another list of 3.0 requirements that I am 
missing.  Any help

[1] https://www.openssl.org/docs/OpenSSL300Design.html

Reply via email to