I am writing this on behalf of the OTC, as an update on the latest OTC developments. This week we had three days of virtual face to face meetings (two OTC sessions with one Committers session in the middle) and we scheduled the next OTC meeting already next week, on Tuesday 2020-10-06.
This email presents some of the points already under discussion since last week, and an agenda proposal for the next OTC meeting. This is done in the interest of transparency and so that the community can give us feedback during the discussion. Background ---------- Understandably, it doesn't come as a surprise that this week we mostly discussed about the upcoming beta release and associated items. According to our [Release Schedule], among our pre-releases, the transition from _alpha_ releases to _beta_ releases is defined by the following definitions: - an _alpha_ release means: - Not (necessarily) feature complete - Not necessarily all new APIs in place yet - a _beta_ release means: - Feature complete/Feature freeze - Bug fixes only >From the discussion, it transpired that the OTC needs to better formalize, in technical terms, how to assess its level of confidence on beta readiness, and to collectively agree on which technical tasks still need to be completed before the transition to beta to ensure feature completeness, and which remaining tasks would count as bug fixes that can be planned for the beta stage. At the next OTC meeting, we plan to discuss mainly two items in our agenda: - discuss, refine and vote on the "Beta Release Readiness Checklist" - discuss, refine and vote on the "Technical items still to be done" list The "Beta Release Readiness Checklist" aims at establishing the technical checks to be performed to assess the OTC degree of confidence on the state of the development branch before calling the OTC "Ready for beta" vote. The "Technical items still to be done" list aims at collecting a number of technical items that we still need to meet in order to qualify for feature completeness against the release requirements provided by the OMC (mainly via the [3.0 design document] and the [Release Strategy]). This list requires further review to check if there are missing items that were overlooked, to refine and compare different interpretations of how the OTC should deduce technical items out of the OMC provided requirements, or to improve the description of how to technically meet those requirements. On the prerogatives of OTC and OMC ---------------------------------- To better frame the community discussion following this announcement, it is worth to recall here an excerpt (listing only the items that are relevant in the context of these drafts) from the [OpenSSL Bylaws], according to which - the OpenSSL Technical Committee (OTC) - makes all technical decision of the code and documentation for OpenSSL; - produces releases according to OMC requirements; - establishes and maintains technical policies and technical procedures; - the OpenSSL Management Committee (OMC) - makes all decisions regarding management and strategic direction of the project, including: * business requirements; * feature requirements; * platform requirements; * roadmap requirements and priority; * release timing and requirement decisions; - sets and maintains all non-technical policies and non-technical procedures; - schedules releases and determines future release plans and the development roadmap and priorities. It follows that the scope of the OTC discussion regarding both lists, and the feedback we can invite from the community, is limited to technical policies and procedures to produce releases according to the requirements provided by the OMC, and should not include items that belong only to the OMC prerogatives. --- The rest of this email provides the **drafts** of the two lists as the result of our preliminary discussions, to collect feedback from the wider community for consideration in the decision process. **NOTE**: I must reiterate that the following lists are both in a **draft** state, with some items deliberately in the form of discussion points. At the end of the process it is likely for some items to be rephrased, altered in scope, or dropped, as it is likely that entirely new items might be added. Both drafts are just **proposals**: they have not been adopted by the OTC yet, they might still not be adopted at the end of the decision process, and their scopes, goals and titles might still be changed. --- Proposed "Beta Release Readiness Checklist" ------------------------------------------- 01. Functionally complete 02. Public API freeze. An application that works with beta1 should work with all subsequent versions. 03. Triage all open issues and decide: not an issue, won’t fix, fix for beta or fix after beta for each. 04. Triage all TODO(current release) items: done, won’t fix, fix for beta or fix after beta for each. 05. Triage all Coverity issues and close either: by marking it as false positive or by fixing it. 06. Coveralls coverage has not decreased overall from the previous release. 07. Have a pass through all new/changed APIs to ensure consistency, fixing those that aren't. 08. Confirm that all new public APIs are documented. 09. Check that new exported symbols (in the static build) are named correctly (`OSSL_` resp. `ossl_` prefix). 10. Run the previous (all relevant supported) release test suites against the beta version. 11. Clean builds in Travis and Appveyor for two days. 12. run-checker.sh succeeds on 2 consecutive days before release. 13. A passing OTC "ready for beta" vote. Proposed "Technical items still to be done" list ------------------------------------------------ 1. The `EVP` interface is the recommended API, it must be feature-complete compared with the functionality available using lower-level APIs. - Anything that isn't available must be put to an OTC vote to exclude. - The `apps/` are the minimum bar for this, they should not use internal nor deprecated functions (except `speed`, `engine` and the code to handle the `-engine` CLI option). - Deprecated functions used by `libssl` should be moved to an independent file. 2. Deprecation List Proposal: The entire `DH_`, `DSA_`, `ECDH_`, `ECDSA_`, `EC_KEY_`, `RSA_`, and `RAND_METHOD_` interfaces. - Does not include macros defining useful values (e.g. DH maximum size). - Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. - There might be some others. - Review for exceptions. - Rewrite apps to use non-deprecated interfaces as far as possible. - Transfer old apps to test cases (either directly or via 1.1.1). 3. Compile a list of things we know are not present - including things we have removed. 4. We need to have a mapping table from “old names” for things into the 5. We need to have mapping tables for various `d2i`/`i2d` functions. `OSSL_PARAMS` names. 6. We need to rewrite the apps to use only the non-deprecated interfaces (except for the list, speed and engine apps and the engine parameter in various places). 7. All the legacy interfaces need to have their documentation pointing to the replacement interfaces. --- Best regards, Nicola Tuveri [Release Strategy]: https://www.openssl.org/policies/releasestrat.html [OpenSSL Bylaws]: https://www.openssl.org/policies/omc-bylaws.html [3.0 design document]: https://www.openssl.org/docs/OpenSSL300Design.html