Re: [openssl-project] 1.1.1 Release timetable (again)
In message on Wed, 24 Jan 2018 20:48:54 +, Matt Caswell said: matt> On 24/01/18 19:12, Salz, Rich wrote: matt> > A monthly release cadence for beta seems too long. I would prefer two weeks. And we keep doing that until TLS 1.3 is published. matt> matt> That might be ok. As a technical issue though we can only have a maximum matt> of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER matt> in opensslv.h). If we were to do a release every 2 weeks starting on matt> 14th Feb, that would mean the last beta we could possibly do would be on matt> 15th August. If there is a risk that the TLSv1.3 publication could go matt> beyond that date then we would be stuck. This is the first time, as far as I recall, that we've decided to wait on someone else for our releases, so I'm thinking that we have the freedom to decide how to act if there's a delay, for example to delay our own beta cycle. It shouldn't be too hard to write a kind of "caveat emptor" where we say that "should the TLSv1.3 publication be delayed, we till re-evaluate our plans". (another way to do it is to refuse making a release plan before we receive a clear signal that publication *will* happen and when it will... after all, we *are* putting ourselves in a kind of hostage situation) Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] 1.1.1 Release timetable (again)
So a few months into it, we look at changing the schedule if we need to stretch thing out. On 1/24/18, 3:49 PM, "Matt Caswell" wrote: On 24/01/18 19:12, Salz, Rich wrote: > A monthly release cadence for beta seems too long. I would prefer two weeks. And we keep doing that until TLS 1.3 is published. That might be ok. As a technical issue though we can only have a maximum of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER in opensslv.h). If we were to do a release every 2 weeks starting on 14th Feb, that would mean the last beta we could possibly do would be on 15th August. If there is a risk that the TLSv1.3 publication could go beyond that date then we would be stuck. Matt > > > On 1/24/18, 12:32 PM, "Matt Caswell" wrote: > > Reviving the 1.1.1 release timetable discussion now that we have a > clearer idea of the scope of outstanding issues/PRs. > > Here is my updated straw man proposal for the 1.1.1 release timetable. > The only changes to this from my original proposal is to shift the dates > (because in my original proposal we would already have done the first > alpha) and I have relabelled the second release as a "beta". My original > plan called this an alpha with feature freeze at the same time, which > people (vehemently) objected to. :-) > > 14th February 2018, alpha release 1 (pre1) > 14th March 2018, beta release 1 (pre2) > OpenSSL_1_1_1-stable created (feature freeze) > master becomes basis for 1.1.2 or 1.2.0 (TBD) > 11th March 2018, beta release 2 (pre3) > 9th May 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) > > 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 > > My proposed release criteria are: > - All open github issues/PRs older than 2 weeks at the time of release > to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 > milestone to be closed (see below) > - Clean builds in Travis and Appveyor for two days > - run-checker.sh to be showing as clean 2 days before release > - No open Coverity issues (not flagged as "False Positive" or "Ignore") > - TLSv1.3 RFC published > > Valid reasons for closing an issue/PR with a 1.1.1 milestone might be: > - We have just now or sometime in the past fixed the issue > - Unable to reproduce (following discussion with original reporter if > possible) > - Working as intended > - Deliberate decision not to fix until a later release (this wouldn't > actually close the issue/PR but change the milestone instead) > - Not enough information and unable to contact reporter > - etc > > This plan gives us 2 months from feature freeze to get all issues and > PRs with the 1.1.1 milestone closed (or assigned to a different > milestone). Currently this stands at 141 issues and 55 PRs. In practice > I think the only way we get through that lot is to make explicit > decisions not to fix/implement some of them and change the milestone. > But I think making explicit decisions about these rather than just > letting them drift indefinitely is a good thing. > > If the TLSv1.3 RFC is not published by the time we are ready to release, > or we haven't made the progress we want on the other release criteria > then we can add additional betas as we see fit until such time as we are > ready. > > Matt > ___ > openssl-project mailing list > openssl-project@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > > > ___ > openssl-project mailing list > openssl-project@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] 1.1.1 Release timetable (again)
On 24/01/18 19:12, Salz, Rich wrote: > A monthly release cadence for beta seems too long. I would prefer two weeks. > And we keep doing that until TLS 1.3 is published. That might be ok. As a technical issue though we can only have a maximum of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER in opensslv.h). If we were to do a release every 2 weeks starting on 14th Feb, that would mean the last beta we could possibly do would be on 15th August. If there is a risk that the TLSv1.3 publication could go beyond that date then we would be stuck. Matt > > > On 1/24/18, 12:32 PM, "Matt Caswell" wrote: > > Reviving the 1.1.1 release timetable discussion now that we have a > clearer idea of the scope of outstanding issues/PRs. > > Here is my updated straw man proposal for the 1.1.1 release timetable. > The only changes to this from my original proposal is to shift the dates > (because in my original proposal we would already have done the first > alpha) and I have relabelled the second release as a "beta". My original > plan called this an alpha with feature freeze at the same time, which > people (vehemently) objected to. :-) > > 14th February 2018, alpha release 1 (pre1) > 14th March 2018, beta release 1 (pre2) > OpenSSL_1_1_1-stable created (feature freeze) > master becomes basis for 1.1.2 or 1.2.0 (TBD) > 11th March 2018, beta release 2 (pre3) > 9th May 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) > > 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 > > My proposed release criteria are: > - All open github issues/PRs older than 2 weeks at the time of release > to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 > milestone to be closed (see below) > - Clean builds in Travis and Appveyor for two days > - run-checker.sh to be showing as clean 2 days before release > - No open Coverity issues (not flagged as "False Positive" or "Ignore") > - TLSv1.3 RFC published > > Valid reasons for closing an issue/PR with a 1.1.1 milestone might be: > - We have just now or sometime in the past fixed the issue > - Unable to reproduce (following discussion with original reporter if > possible) > - Working as intended > - Deliberate decision not to fix until a later release (this wouldn't > actually close the issue/PR but change the milestone instead) > - Not enough information and unable to contact reporter > - etc > > This plan gives us 2 months from feature freeze to get all issues and > PRs with the 1.1.1 milestone closed (or assigned to a different > milestone). Currently this stands at 141 issues and 55 PRs. In practice > I think the only way we get through that lot is to make explicit > decisions not to fix/implement some of them and change the milestone. > But I think making explicit decisions about these rather than just > letting them drift indefinitely is a good thing. > > If the TLSv1.3 RFC is not published by the time we are ready to release, > or we haven't made the progress we want on the other release criteria > then we can add additional betas as we see fit until such time as we are > ready. > > Matt > ___ > openssl-project mailing list > openssl-project@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > > > ___ > openssl-project mailing list > openssl-project@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] 1.1.1 Release timetable (again)
A monthly release cadence for beta seems too long. I would prefer two weeks. And we keep doing that until TLS 1.3 is published. On 1/24/18, 12:32 PM, "Matt Caswell" wrote: Reviving the 1.1.1 release timetable discussion now that we have a clearer idea of the scope of outstanding issues/PRs. Here is my updated straw man proposal for the 1.1.1 release timetable. The only changes to this from my original proposal is to shift the dates (because in my original proposal we would already have done the first alpha) and I have relabelled the second release as a "beta". My original plan called this an alpha with feature freeze at the same time, which people (vehemently) objected to. :-) 14th February 2018, alpha release 1 (pre1) 14th March 2018, beta release 1 (pre2) OpenSSL_1_1_1-stable created (feature freeze) master becomes basis for 1.1.2 or 1.2.0 (TBD) 11th March 2018, beta release 2 (pre3) 9th May 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) 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 My proposed release criteria are: - All open github issues/PRs older than 2 weeks at the time of release to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 milestone to be closed (see below) - Clean builds in Travis and Appveyor for two days - run-checker.sh to be showing as clean 2 days before release - No open Coverity issues (not flagged as "False Positive" or "Ignore") - TLSv1.3 RFC published Valid reasons for closing an issue/PR with a 1.1.1 milestone might be: - We have just now or sometime in the past fixed the issue - Unable to reproduce (following discussion with original reporter if possible) - Working as intended - Deliberate decision not to fix until a later release (this wouldn't actually close the issue/PR but change the milestone instead) - Not enough information and unable to contact reporter - etc This plan gives us 2 months from feature freeze to get all issues and PRs with the 1.1.1 milestone closed (or assigned to a different milestone). Currently this stands at 141 issues and 55 PRs. In practice I think the only way we get through that lot is to make explicit decisions not to fix/implement some of them and change the milestone. But I think making explicit decisions about these rather than just letting them drift indefinitely is a good thing. If the TLSv1.3 RFC is not published by the time we are ready to release, or we haven't made the progress we want on the other release criteria then we can add additional betas as we see fit until such time as we are ready. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] 1.1.1 Release timetable (again)
On 24/01/18 17:32, Matt Caswell wrote: > 14th March 2018, beta release 1 (pre2) > OpenSSL_1_1_1-stable created (feature freeze) > master becomes basis for 1.1.2 or 1.2.0 (TBD) > 11th March 2018, beta release 2 (pre3) That should of course say 11th April. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] 1.1.1 Release timetable (again)
Reviving the 1.1.1 release timetable discussion now that we have a clearer idea of the scope of outstanding issues/PRs. Here is my updated straw man proposal for the 1.1.1 release timetable. The only changes to this from my original proposal is to shift the dates (because in my original proposal we would already have done the first alpha) and I have relabelled the second release as a "beta". My original plan called this an alpha with feature freeze at the same time, which people (vehemently) objected to. :-) 14th February 2018, alpha release 1 (pre1) 14th March 2018, beta release 1 (pre2) OpenSSL_1_1_1-stable created (feature freeze) master becomes basis for 1.1.2 or 1.2.0 (TBD) 11th March 2018, beta release 2 (pre3) 9th May 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published) 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 My proposed release criteria are: - All open github issues/PRs older than 2 weeks at the time of release to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 milestone to be closed (see below) - Clean builds in Travis and Appveyor for two days - run-checker.sh to be showing as clean 2 days before release - No open Coverity issues (not flagged as "False Positive" or "Ignore") - TLSv1.3 RFC published Valid reasons for closing an issue/PR with a 1.1.1 milestone might be: - We have just now or sometime in the past fixed the issue - Unable to reproduce (following discussion with original reporter if possible) - Working as intended - Deliberate decision not to fix until a later release (this wouldn't actually close the issue/PR but change the milestone instead) - Not enough information and unable to contact reporter - etc This plan gives us 2 months from feature freeze to get all issues and PRs with the 1.1.1 milestone closed (or assigned to a different milestone). Currently this stands at 141 issues and 55 PRs. In practice I think the only way we get through that lot is to make explicit decisions not to fix/implement some of them and change the milestone. But I think making explicit decisions about these rather than just letting them drift indefinitely is a good thing. If the TLSv1.3 RFC is not published by the time we are ready to release, or we haven't made the progress we want on the other release criteria then we can add additional betas as we see fit until such time as we are ready. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Issues review
I have now also reviewed the PRs. We currently have 144 PRs open: PRs against 1.0.2: 6 PRs against 1.1.0: 7 PRs against 1.1.1: 55 PRs against 1.2.0: 9 PRs against Post 1.1.1: 63 PRs against Other: 2 I was quite strict about allocating PRs to a milestone. This might mean that some of those decisions are controversial. Basically if a PR was about adding a feature, and it wasn't directly TLSv1.3 related (which is the stated primary objective for the release) then I put it against the Post 1.1.1 milestone. This does *not* mean that I think that a PR flagged as "Post 1.1.1" shouldn't go into 1.1.1. It just means that it is not relevant as far as the release criteria go - if it makes it into the release then great; if it doesn't - well we're not going to hold up the release schedule for it. If there are individual cases where you think a PR absolutely *MUST* go into 1.1.1 for whatever reason (to the point that we should hold up the release schedule for it) then we can argue that out on a case-by-case basis and amend the milestones accordingly. Alternatively just make sure you get it reviewed and committed before feature freeze. Matt On 23/01/18 17:49, Matt Caswell wrote: > I completed my first pass review of all issues. I still need to look at > PRs. I have put all PRs against a milestone using the following criteria: > > If it only applies to 1.0.2 or below: 1.0.2 milestone > If it only applies to 1.1.0 or below: 1.1.0 milesone > If it's API/ABI breaking to fix: 1.2.0 milestone > If it's a feature request that we aren't already planning to do for > 1.1.1: Post 1.1.1 milestone > If it's something which is independent of a release (e.g. web issues, > policy/procedure etc): Other milestone > If it applies to master and doesn't fit into one of the categories > above: 1.1.1 milestone > > > Some stats: > > We now have 249 issues open. > Since I started this exercise we have closed 134 issues. > Issues against 1.0.2: 17 > Issues against 1.1.0: 3 > Issues against 1.1.1: 141 > Issues against 1.2.0: 15 > Issues against Post 1.1.1: 58 > Issues against Other: 15 > > > Matt > ___ > openssl-project mailing list > openssl-project@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Speaking of releases, did we finalize a release plan for 1.1.1?
On 24/01/18 13:10, Richard Levitte wrote: > I can't seem to remember a final agreement... last thing I remember > is a disagreement of what "the last alpha" means in practice, and that > I finally got Matt's point with having it being a feature freeze in > practice. But a final release plan, I can't remember one. > > Time to reiterate this, perhaps? > There was some debate around how many/how long the release cycles should be. Part of the problem was that it is difficult to quantify the amount of work required to close off old issues (assuming we go with my proposed release criteria). That is the motivation for the work I have been doing reviewing the issues (and now the PRs). I have been going through them all and assigning a milestone to them. When I have completed that work I will revive the discussion on release plan. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Speaking of releases, did we finalize a release plan for 1.1.1?
I can't seem to remember a final agreement... last thing I remember is a disagreement of what "the last alpha" means in practice, and that I finally got Matt's point with having it being a feature freeze in practice. But a final release plan, I can't remember one. Time to reiterate this, perhaps? -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Welcome Dr. Matthias St. Pierre
Welcome! On Tue, Jan 23, 2018 at 11:55 PM Richard Levitte wrote: > In message on Tue, 23 > Jan 2018 16:35:02 +, "Salz, Rich" said: > > rsalz> In a little while, Richard should have his SSH keys integrated > rsalz> into our systems, and will email him some more detailed > rsalz> instructions. > > Done and done! Welcome, Matthias > > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > ___ > openssl-project mailing list > openssl-project@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
