[openssl-project] platforms

[Tim Hudson]

Currently having a configuration entry actually means nothing - it does not
state if a platform builds, works, tests, etc. It is just a definition. We
claim no particular status in those terms for a platform.

The only thing we have is the platform policy and it lists a very small set
of primary and secondary platforms - but also does not map those to
configuration platform names.
It isn't about does-it-work or not - it is about does someone "support" it.
That is how the platform policy is explicitly defined.

Absent someone specifically putting their hand up to say they will
"support" a platform, the platform belongs in unknown.
This is not about does-it-work. This is about its support status.

The current objective and focus is to actually put each definition into our
already defined categories according to our platform policy.
Once that is done we can figure out more in terms of what we want to expand
the platform policy to mean in terms of specifics beyond "supported".

Now I do indeed think we should go beyond that - and that means defining
criteria for what we mean by a platform definition going forward - and
right now that isn't defined.
We have a lot of platform definitions where make test simply does not work.

If someone hasn't volunteered explicitly to support a platform then it is
"unknown" or "deprecated" ... those are the available choices.

And Configure should note the status of the platform too in terms of which
category it is in - to encourage people to step forward to "support" a
platform.

Tim.


On Thu, Jan 11, 2018 at 8:07 AM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180111/37a50757/attachment-0001.html>