[openssl-project] platforms
Salz, Rich
rsalz at akamai.com
Wed Jan 10 22:34:23 UTC 2018
UEFI is one such exception
On 1/10/18, 5:07 PM, "Richard Levitte" <levitte at openssl.org> wrote:
I'd say that for the "big" platforms, we do require full build and
full test to say that "it works". I would say that should be the base
criteria we work with.
But then, I can see reasons to make exceptions from these criteria.
As you say, on some platforms, only the libraries are built. I can
also imagine a situation where we cross compile everything, and perl
isn't available on the target architecture, which makes our tests
impossible. These should be noted for sure if we decide to support
them, but *as exceptions* to the base criteria.
In message <CAHEJ-S74_mCgmHzUYsmkuv=rrSW-9=gX0nLreARdES_bSeNcow at mail.gmail.com> on Wed, 10 Jan 2018 17:21:34 +1000, Tim Hudson <tjh at cryptsoft.com> said:
tjh> Follow on from the discussion in PR#5035, I think we need to add a "status" definition to the
tjh> platform which should cover the different contexts:
tjh>
tjh> 1) libraries compile
tjh> 2) apps compile
tjh> 3) make test passes
tjh>
tjh> We have platforms where we don't compile the apps and we have platforms where there are
tjh> issues in the tests - i.e. the library (with or without the apps) compiles and operates correctly but
tjh> there is a defect in the tests.
tjh> Defects in tests or defects in the apps are different to defects in the libraries.
tjh> The apps not being ported also does not mean the platform is unusable.
tjh>
tjh> That level of differences should be recorded. Perhaps a status for each?
tjh>
tjh> - libcrypto
tjh> - libssl
tjh> - apps
tjh> - tests
tjh>
tjh> For many platforms, the apps and the tests simply don't work or are not used; and our test
tjh> automation platform also does not operate for many platforms.
tjh>
tjh> Tim.
tjh>
tjh> On Wed, Jan 10, 2018 at 11:48 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:
tjh>
tjh> On Tue, Jan 09, 2018 at 01:12:56PM +0100, Richard Levitte wrote:
tjh> > Speaking of platforms, I think we need to discuss what we actually
tjh> > include in the secondary category. The platform policy currently
tjh> > mentions these:
tjh> >
tjh> > FreeBSD, Windows (Visual Studio, MinGW), MacOS X and VMS
tjh> >
tjh> > For Windows and VMS, I know for sure that it follows our definition of
tjh> > the secondary category (*), but for FreeBSD and MacOS X, I think we
tjh> > may have lost the people who actively supported them (for FreeBSD,
tjh> > that was Ben Laurie as far as I recall).
tjh> >
tjh> > So I think we need a raise of hands, here and now:
tjh> >
tjh> > 1. Is there anyone currently present on this list that want to take
tjh> > on FreeBSD or MacOS X?
tjh>
tjh> I guess maybe this is overcome by events since I commented on github
tjh> already, but I can take FreeBSD (amd64). I can spin up i386 FreeBSD
tjh> in the lead up to new releases but don't normally use it on a
tjh> regular basis.
tjh>
tjh> -Ben
tjh> _______________________________________________
tjh> openssl-project mailing list
tjh> openssl-project at openssl.org
tjh> https://mta.openssl.org/mailman/listinfo/openssl-project
tjh>
_______________________________________________
openssl-project mailing list
openssl-project at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
More information about the openssl-project
mailing list