[openssl-dev] Please consider delaying the Beta-1 freeze for a week or two

Jeffrey Walton noloader at gmail.com
Fri Mar 11 09:24:00 UTC 2016

> noloader> Testing master on real hardware is showing some minor issues on a few
> noloader> platforms, including ARM32, ARM64, PowerPC and i686. In addition,
> noloader> there seems to be one-off issues on other combinations, like VIA's C7
> noloader> processor on Linux.
> noloader>
> noloader> In addition to the base issues, there are other minor issues like
> noloader> failing to configure and compile with 'no-comp'. Other configuration
> noloader> dependent issues include failed self tests under PowerPC in a shared
> noloader> configuration.
> noloader>
> noloader> Please consider delaying the freeze for a week or two while the issues
> noloader> are being ironed out.
> The upcoming release is the first beta of two planned, and we've
> already delayed the first for a few extra days.  It is not a final
> release, so there's still time to fix things like these.
> Please see the bottom of the release strategy for the planned dates:
> http://openssl.org/policies/releasestrat.html

Well, would it be possible to survey supported platforms and see if it
makes sense to move forward at this point? Does the library maintain a
matrix of test platforms and results?

Releasing a Beta-1 seems like its missing the point if the the point
of the beta is to test it. There are issues in {configure|build|test}
on ARM32, ARM64, OpenBSD, Windows and some Linux i686 and x86_64
targets/configurations. I'm also wondering about MIPS, NetBSD, FreeBSD
and Gentoo.

Maybe something else to ponder in the big picture of release
engineering... Why are the breaks occurring and not being caught? Why
is the engineering process not catching them?

(I think its OK to break things on occasion. You can't make an omelet
without breaking eggs. But the idea is you have to catch them quickly
and early before the user experiences the pain point. If the break is
fixed before the user experiences the pain, then it "no blood, no
foul" in my book).

There's no need to rush the process. OpenSSL does not answer to anyone
except its own quality standards. It seems like stepping back, coming
up for some air, catching your breath and then diving back in will
produce better results in the end.


More information about the openssl-dev mailing list