[openssl-project] 1.1.1 Release timetable (again)

[Matt Caswell]

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