[OTC] Agenda proposal for OTC meeting on 2020-10-06

Nicola Tuveri nic.tuv at gmail.com
Fri Oct 2 20:55:51 UTC 2020

I am writing this on behalf of the OTC, as an update on the latest OTC
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.


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

- discuss, refine and vote on the "Beta Release Readiness Checklist"
- discuss, refine and vote on the "Technical items still to be done"

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
  - produces releases according to OMC requirements;
  - establishes and maintains technical policies and technical
- 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
  - 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
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
   - 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
   - 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

More information about the openssl-project mailing list