Re: [OTC] Agenda proposal for OTC meeting on 2020-10-06
[Resending this, to incorporate an errata in the second list, at points 4 and 5] 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: n
[OTC] Agenda proposal for OTC meeting on 2020-10-06
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 TO