Re: 3.0 release timeline proposal

[Matt Caswell]

On 16/01/2020 10:39, Matt Caswell wrote:
> This vote has started. I'll report back when we have an answer.

The vote has now finished with these results:

+1: 7
 0: 0
-1: 0

So the vote passed.

Matt



> 
> Matt
> 
> On 15/01/2020 09:12, Matt Caswell wrote:
>> Not much feedback, so I'm assuming everyone is ok with this proposal.
>>
>> I'm going to start a vote soon with this wording:
>>
>> "Update the release strategy to the text shown here:
>> https://github.com/openssl/web/pull/154/commits/959153c7e62865beae9f24364f1c971b149f477a";
>>
>>
>>
>> Matt
>>
>>
>>
>>
>> On 07/01/2020 16:54, Matt Caswell wrote:
>>> I converted this proposal into a PR to amend the release strategy.
>>> Please see:
>>>
>>> https://github.com/openssl/web/pull/154
>>>
>>> Matt
>>>
>>>
>>> On 07/01/2020 11:13, Matt Caswell wrote:
 Hi all

 Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
 the outstanding tasks and effort required to get us to a final release.

 We've previously said this about that timeline:

 "We are now not expecting code completion to occur until the end of Q2
 2020 with a final release in early Q4 2020."
 (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)


 With that in mind we came up with the following proposal for a release
 timetable which we think is a challenging but achievable timeline:

 alpha1, 2020-03-31: Basic functionality plus basic FIPS module
 alpha2, 2020-04-21: Complete external provider support (serialization,
 support for new algs, support for providers which only include
 operations in a class)
 alpha3, 2020-05-21: Almost there (aiming to test the API completeness
 before beta1 freezes it)
 beta1, 2020-06-02: Code complete (API stable, feature freeze)
 betaN: Other beta TBD
 Final: 2020 early Q4

 The idea here is to set some intermediate deadlines to focus attention
 on the final remaining tasks, with a series of 3 alphas prior to the
 first beta release where each alpha release comes approximately every 3
 weeks. We can have some flexibility to adjust this timetable if we think
 it is necessary (such as by including an additional alpha release if
 required).

 Please let me know your thoughts. This would probably need to go to an
 OMC vote to get approved.

 Matt

> 

Re: 3.0 release timeline proposal

[Matt Caswell]

This vote has started. I'll report back when we have an answer.

Matt

On 15/01/2020 09:12, Matt Caswell wrote:
> Not much feedback, so I'm assuming everyone is ok with this proposal.
> 
> I'm going to start a vote soon with this wording:
> 
> "Update the release strategy to the text shown here:
> https://github.com/openssl/web/pull/154/commits/959153c7e62865beae9f24364f1c971b149f477a";
> 
> 
> 
> Matt
> 
> 
> 
> 
> On 07/01/2020 16:54, Matt Caswell wrote:
>> I converted this proposal into a PR to amend the release strategy.
>> Please see:
>>
>> https://github.com/openssl/web/pull/154
>>
>> Matt
>>
>>
>> On 07/01/2020 11:13, Matt Caswell wrote:
>>> Hi all
>>>
>>> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
>>> the outstanding tasks and effort required to get us to a final release.
>>>
>>> We've previously said this about that timeline:
>>>
>>> "We are now not expecting code completion to occur until the end of Q2
>>> 2020 with a final release in early Q4 2020."
>>> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
>>>
>>>
>>> With that in mind we came up with the following proposal for a release
>>> timetable which we think is a challenging but achievable timeline:
>>>
>>> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
>>> alpha2, 2020-04-21: Complete external provider support (serialization,
>>> support for new algs, support for providers which only include
>>> operations in a class)
>>> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
>>> before beta1 freezes it)
>>> beta1, 2020-06-02: Code complete (API stable, feature freeze)
>>> betaN: Other beta TBD
>>> Final: 2020 early Q4
>>>
>>> The idea here is to set some intermediate deadlines to focus attention
>>> on the final remaining tasks, with a series of 3 alphas prior to the
>>> first beta release where each alpha release comes approximately every 3
>>> weeks. We can have some flexibility to adjust this timetable if we think
>>> it is necessary (such as by including an additional alpha release if
>>> required).
>>>
>>> Please let me know your thoughts. This would probably need to go to an
>>> OMC vote to get approved.
>>>
>>> Matt
>>>

Re: 3.0 release timeline proposal

[Matt Caswell]

Not much feedback, so I'm assuming everyone is ok with this proposal.

I'm going to start a vote soon with this wording:

"Update the release strategy to the text shown here:
https://github.com/openssl/web/pull/154/commits/959153c7e62865beae9f24364f1c971b149f477a";



Matt




On 07/01/2020 16:54, Matt Caswell wrote:
> I converted this proposal into a PR to amend the release strategy.
> Please see:
> 
> https://github.com/openssl/web/pull/154
> 
> Matt
> 
> 
> On 07/01/2020 11:13, Matt Caswell wrote:
>> Hi all
>>
>> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
>> the outstanding tasks and effort required to get us to a final release.
>>
>> We've previously said this about that timeline:
>>
>> "We are now not expecting code completion to occur until the end of Q2
>> 2020 with a final release in early Q4 2020."
>> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
>>
>>
>> With that in mind we came up with the following proposal for a release
>> timetable which we think is a challenging but achievable timeline:
>>
>> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
>> alpha2, 2020-04-21: Complete external provider support (serialization,
>> support for new algs, support for providers which only include
>> operations in a class)
>> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
>> before beta1 freezes it)
>> beta1, 2020-06-02: Code complete (API stable, feature freeze)
>> betaN: Other beta TBD
>> Final: 2020 early Q4
>>
>> The idea here is to set some intermediate deadlines to focus attention
>> on the final remaining tasks, with a series of 3 alphas prior to the
>> first beta release where each alpha release comes approximately every 3
>> weeks. We can have some flexibility to adjust this timetable if we think
>> it is necessary (such as by including an additional alpha release if
>> required).
>>
>> Please let me know your thoughts. This would probably need to go to an
>> OMC vote to get approved.
>>
>> Matt
>>

Re: 3.0 release timeline proposal

[Matt Caswell]

I converted this proposal into a PR to amend the release strategy.
Please see:

https://github.com/openssl/web/pull/154

Matt


On 07/01/2020 11:13, Matt Caswell wrote:
> Hi all
> 
> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
> the outstanding tasks and effort required to get us to a final release.
> 
> We've previously said this about that timeline:
> 
> "We are now not expecting code completion to occur until the end of Q2
> 2020 with a final release in early Q4 2020."
> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> 
> 
> With that in mind we came up with the following proposal for a release
> timetable which we think is a challenging but achievable timeline:
> 
> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> alpha2, 2020-04-21: Complete external provider support (serialization,
> support for new algs, support for providers which only include
> operations in a class)
> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
> before beta1 freezes it)
> beta1, 2020-06-02: Code complete (API stable, feature freeze)
> betaN: Other beta TBD
> Final: 2020 early Q4
> 
> The idea here is to set some intermediate deadlines to focus attention
> on the final remaining tasks, with a series of 3 alphas prior to the
> first beta release where each alpha release comes approximately every 3
> weeks. We can have some flexibility to adjust this timetable if we think
> it is necessary (such as by including an additional alpha release if
> required).
> 
> Please let me know your thoughts. This would probably need to go to an
> OMC vote to get approved.
> 
> Matt
> 

Re: 3.0 release timeline proposal

[Dmitry Belyavsky]

Sorry. My fault :(

On Tue, 7 Jan 2020, 16:35 Matt Caswell,  wrote:

>
>
> On 07/01/2020 13:26, Dmitry Belyavsky wrote:
> > Many thanks!
> >
> > Got it, and I think this should be directly written.
>
> It was!!
>
> beta1, 2020-06-02: Code complete (API stable, feature freeze)
>
>
> Matt
>
>
> >
> > On Tue, 7 Jan 2020, 16:05 Matt Caswell,  > > wrote:
> >
> >
> >
> > On 07/01/2020 13:00, Dmitry Belyavsky wrote:
> > > When does the feature freeze happen?
> > > I'm interested in publishing as much GOST support as possible.
> >
> > According to my proposal feature freeze would happen on release of
> > beta1, i.e. 2020-06-02.
> >
> > Matt
> >
> >
> > >
> > > On Tue, 7 Jan 2020, 14:13 Matt Caswell,  > 
> > > >> wrote:
> > >
> > > Hi all
> > >
> > > Myself, Paul, Shane, Richard and Nicola had a conf call today
> > to discuss
> > > the outstanding tasks and effort required to get us to a final
> > release.
> > >
> > > We've previously said this about that timeline:
> > >
> > > "We are now not expecting code completion to occur until the
> > end of Q2
> > > 2020 with a final release in early Q4 2020."
> > > (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> > >
> > >
> > > With that in mind we came up with the following proposal for a
> > release
> > > timetable which we think is a challenging but achievable
> timeline:
> > >
> > > alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> > > alpha2, 2020-04-21: Complete external provider support
> > (serialization,
> > > support for new algs, support for providers which only include
> > > operations in a class)
> > > alpha3, 2020-05-21: Almost there (aiming to test the API
> > completeness
> > > before beta1 freezes it)
> > > beta1, 2020-06-02: Code complete (API stable, feature freeze)
> > > betaN: Other beta TBD
> > > Final: 2020 early Q4
> > >
> > > The idea here is to set some intermediate deadlines to focus
> > attention
> > > on the final remaining tasks, with a series of 3 alphas prior
> > to the
> > > first beta release where each alpha release comes
> > approximately every 3
> > > weeks. We can have some flexibility to adjust this timetable
> > if we think
> > > it is necessary (such as by including an additional alpha
> > release if
> > > required).
> > >
> > > Please let me know your thoughts. This would probably need to
> > go to an
> > > OMC vote to get approved.
> > >
> > > Matt
> > >
> >
>

Re: 3.0 release timeline proposal

[Matt Caswell]

On 07/01/2020 13:26, Dmitry Belyavsky wrote:
> Many thanks!
> 
> Got it, and I think this should be directly written. 

It was!!

beta1, 2020-06-02: Code complete (API stable, feature freeze)


Matt


> 
> On Tue, 7 Jan 2020, 16:05 Matt Caswell,  > wrote:
> 
> 
> 
> On 07/01/2020 13:00, Dmitry Belyavsky wrote:
> > When does the feature freeze happen?
> > I'm interested in publishing as much GOST support as possible.
> 
> According to my proposal feature freeze would happen on release of
> beta1, i.e. 2020-06-02.
> 
> Matt
> 
> 
> >
> > On Tue, 7 Jan 2020, 14:13 Matt Caswell,  
> > >> wrote:
> >
> >     Hi all
> >
> >     Myself, Paul, Shane, Richard and Nicola had a conf call today
> to discuss
> >     the outstanding tasks and effort required to get us to a final
> release.
> >
> >     We've previously said this about that timeline:
> >
> >     "We are now not expecting code completion to occur until the
> end of Q2
> >     2020 with a final release in early Q4 2020."
> >     (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> >
> >
> >     With that in mind we came up with the following proposal for a
> release
> >     timetable which we think is a challenging but achievable timeline:
> >
> >     alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> >     alpha2, 2020-04-21: Complete external provider support
> (serialization,
> >     support for new algs, support for providers which only include
> >     operations in a class)
> >     alpha3, 2020-05-21: Almost there (aiming to test the API
> completeness
> >     before beta1 freezes it)
> >     beta1, 2020-06-02: Code complete (API stable, feature freeze)
> >     betaN: Other beta TBD
> >     Final: 2020 early Q4
> >
> >     The idea here is to set some intermediate deadlines to focus
> attention
> >     on the final remaining tasks, with a series of 3 alphas prior
> to the
> >     first beta release where each alpha release comes
> approximately every 3
> >     weeks. We can have some flexibility to adjust this timetable
> if we think
> >     it is necessary (such as by including an additional alpha
> release if
> >     required).
> >
> >     Please let me know your thoughts. This would probably need to
> go to an
> >     OMC vote to get approved.
> >
> >     Matt
> >
> 

Re: 3.0 release timeline proposal

[Dmitry Belyavsky]

Many thanks!

Got it, and I think this should be directly written.

On Tue, 7 Jan 2020, 16:05 Matt Caswell,  wrote:

>
>
> On 07/01/2020 13:00, Dmitry Belyavsky wrote:
> > When does the feature freeze happen?
> > I'm interested in publishing as much GOST support as possible.
>
> According to my proposal feature freeze would happen on release of
> beta1, i.e. 2020-06-02.
>
> Matt
>
>
> >
> > On Tue, 7 Jan 2020, 14:13 Matt Caswell,  > > wrote:
> >
> > Hi all
> >
> > Myself, Paul, Shane, Richard and Nicola had a conf call today to
> discuss
> > the outstanding tasks and effort required to get us to a final
> release.
> >
> > We've previously said this about that timeline:
> >
> > "We are now not expecting code completion to occur until the end of
> Q2
> > 2020 with a final release in early Q4 2020."
> > (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> >
> >
> > With that in mind we came up with the following proposal for a
> release
> > timetable which we think is a challenging but achievable timeline:
> >
> > alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> > alpha2, 2020-04-21: Complete external provider support
> (serialization,
> > support for new algs, support for providers which only include
> > operations in a class)
> > alpha3, 2020-05-21: Almost there (aiming to test the API completeness
> > before beta1 freezes it)
> > beta1, 2020-06-02: Code complete (API stable, feature freeze)
> > betaN: Other beta TBD
> > Final: 2020 early Q4
> >
> > The idea here is to set some intermediate deadlines to focus
> attention
> > on the final remaining tasks, with a series of 3 alphas prior to the
> > first beta release where each alpha release comes approximately
> every 3
> > weeks. We can have some flexibility to adjust this timetable if we
> think
> > it is necessary (such as by including an additional alpha release if
> > required).
> >
> > Please let me know your thoughts. This would probably need to go to
> an
> > OMC vote to get approved.
> >
> > Matt
> >
>

Re: 3.0 release timeline proposal

[Matt Caswell]

On 07/01/2020 13:00, Dmitry Belyavsky wrote:
> When does the feature freeze happen?
> I'm interested in publishing as much GOST support as possible. 

According to my proposal feature freeze would happen on release of
beta1, i.e. 2020-06-02.

Matt


> 
> On Tue, 7 Jan 2020, 14:13 Matt Caswell,  > wrote:
> 
> Hi all
> 
> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
> the outstanding tasks and effort required to get us to a final release.
> 
> We've previously said this about that timeline:
> 
> "We are now not expecting code completion to occur until the end of Q2
> 2020 with a final release in early Q4 2020."
> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> 
> 
> With that in mind we came up with the following proposal for a release
> timetable which we think is a challenging but achievable timeline:
> 
> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> alpha2, 2020-04-21: Complete external provider support (serialization,
> support for new algs, support for providers which only include
> operations in a class)
> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
> before beta1 freezes it)
> beta1, 2020-06-02: Code complete (API stable, feature freeze)
> betaN: Other beta TBD
> Final: 2020 early Q4
> 
> The idea here is to set some intermediate deadlines to focus attention
> on the final remaining tasks, with a series of 3 alphas prior to the
> first beta release where each alpha release comes approximately every 3
> weeks. We can have some flexibility to adjust this timetable if we think
> it is necessary (such as by including an additional alpha release if
> required).
> 
> Please let me know your thoughts. This would probably need to go to an
> OMC vote to get approved.
> 
> Matt
> 

Re: 3.0 release timeline proposal

[Dmitry Belyavsky]

When does the feature freeze happen?
I'm interested in publishing as much GOST support as possible.

On Tue, 7 Jan 2020, 14:13 Matt Caswell,  wrote:

> Hi all
>
> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
> the outstanding tasks and effort required to get us to a final release.
>
> We've previously said this about that timeline:
>
> "We are now not expecting code completion to occur until the end of Q2
> 2020 with a final release in early Q4 2020."
> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
>
>
> With that in mind we came up with the following proposal for a release
> timetable which we think is a challenging but achievable timeline:
>
> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> alpha2, 2020-04-21: Complete external provider support (serialization,
> support for new algs, support for providers which only include
> operations in a class)
> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
> before beta1 freezes it)
> beta1, 2020-06-02: Code complete (API stable, feature freeze)
> betaN: Other beta TBD
> Final: 2020 early Q4
>
> The idea here is to set some intermediate deadlines to focus attention
> on the final remaining tasks, with a series of 3 alphas prior to the
> first beta release where each alpha release comes approximately every 3
> weeks. We can have some flexibility to adjust this timetable if we think
> it is necessary (such as by including an additional alpha release if
> required).
>
> Please let me know your thoughts. This would probably need to go to an
> OMC vote to get approved.
>
> Matt
>