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

Erik Forsberg erik at efca.com
Fri Mar 11 18:24:13 UTC 2016

add Solaris to the platforms that are not at beta-level yet.
Richard Levitte and myself are helping each other out though, so we should be close

>-- Original Message --
>> 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.
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

More information about the openssl-dev mailing list