Vote proposal: Technical items still to be done

[Salz, Rich]

>    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