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

2020-10-02 Thread Nicola Tuveri 
[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:

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

2020-10-02 Thread Nicola Tuveri 
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

Re: Would this be interesting to the project?

2020-10-02 Thread Dmitry Belyavsky 
As setting up openssl master is required to build gost-engine, I'll have to.

On Fri, Oct 2, 2020 at 4:29 PM Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:

> > Do you have ideas on how to properly set it up?
>
>
>
> Congratulations, Dmitry! You just won the price of being assigned the job
> to figure it out.  ;-)
>
>
>
> Matthias
>
>
>
>
>
> *[image: NCP engingeering GmbH]* *Dr. Matthias St. Pierre*
>
> Senior Software Engineer
> matthias.st.pie...@ncp-e.com
> Phone: +49 911 9968-0
> www.ncp-e.com
>
>
> * Follow us on:* Facebook  |
> Twitter  | Xing
>  | YouTube
>  | LinkedIn
> 
>
> *Headquarters Germany: *NCP engineering GmbH • Dombuehler Str. 2 • 90449
> • Nuremberg
> *North American HQ:* NCP engineering Inc. • 601 Cleveland Str., Suite
> 501-25 • Clearwater, FL 33755
>
> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate
> Dietrich
> Registry Court: Lower District Court of Nuremberg
> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE
> 133557619
>
> This e-mail message including any attachments is for the sole use of the
> intended recipient(s) and may contain privileged or confidential
> information. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please immediately
> contact the sender by reply e-mail and delete the original message and
> destroy all copies thereof.
>
> 
> 
>
> *From**:* openssl-project  *On
> Behalf Of *Dmitry Belyavsky
> *Sent:* Friday, October 2, 2020 2:51 PM
> *To:* Dr Paul Dale 
> *Cc:* openssl-project@openssl.org
> *Subject:* Re: Would this be interesting to the project?
>
>
>
> Do you have ideas on how to properly set it up?
>
>
>
> On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale  wrote:
>
> https://github.blog/2020-09-30-code-scanning-is-now-available/
>
>
>
> Pauli
>
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>


-- 
SY, Dmitry Belyavsky

RE: Would this be interesting to the project?

2020-10-02 Thread Dr. Matthias St. Pierre 
> Do you have ideas on how to properly set it up?

Congratulations, Dmitry! You just won the price of being assigned the job to 
figure it out.  ;-)

Matthias

From: openssl-project  On Behalf Of Dmitry 
Belyavsky
Sent: Friday, October 2, 2020 2:51 PM
To: Dr Paul Dale 
Cc: openssl-project@openssl.org
Subject: Re: Would this be interesting to the project?

Do you have ideas on how to properly set it up?

On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale 
mailto:paul.d...@oracle.com>> wrote:
https://github.blog/2020-09-30-code-scanning-is-now-available/

Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia






--
SY, Dmitry Belyavsky

Re: Would this be interesting to the project?

2020-10-02 Thread Dmitry Belyavsky 
Do you have ideas on how to properly set it up?

On Thu, Oct 1, 2020 at 11:36 AM Dr Paul Dale  wrote:

> https://github.blog/2020-09-30-code-scanning-is-now-available/
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
>

-- 
SY, Dmitry Belyavsky