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