[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
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
More information about the openssl-project
mailing list