[openssl-project] platforms

Tue Jan 9 09:56:24 UTC 2018

In message <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA at mail.gmail.com> on Tue, 9 Jan 2018 17:49:36 +1000, Tim Hudson <tjh at cryptsoft.com> said:

tjh> Given the discussion on PR#5035 it is time to split 10-main.conf into three groups to match the
tjh> platform policy and roadmap in my view.
tjh> 
tjh> 10-primary
tjh> 20-secondary
tjh> 30-community
tjh> 40-unknown
tjh> 50-deprecated

Arbitrary numbers will always be arbitrary.  We've already started
with new community contributed config targets in the 50 group, why
change that?

Also, there's no real reason to have one big monolithic file per
group.  As you can notice from said 50 group, we've already divided
them in smaller things...  per platform family of sorts, maybe?

So may I suggest that we use the groups 10-49 for stuff "known by us"
(i.e. primary and secondary), 50-89 for "not so known by us"
(i.e. community provided, unknown and deprecated), leaving 00-09 for
base templates (*) and 90-99 for "personal" (i.e. team stuff we choose
to share as well as simply leaving space for those who want to
maintain their own inside their copy of our source)?

Finally, I think we used the term "legacy" rather than "deprecated" at
some point.  Would you mind "legacy"?

tjh> Most of the current 10-main should move into 40-unknown - that is
tjh> the reality of our actual context.

Agreed.

tjh> See https://www.openssl.org/policies/platformpolicy.html for the
tjh> policy and https://www.openssl.org/policies/roadmap.html where we
tjh> stated that this would be completed by the next feature release
tjh> (i.e. I think that was 1.1.0 at the time but even if we looked
tjh> from the point of view of "now" that would be 1.1.1). We missed
tjh> that timeline.

The statements about next feature release were added as off this
commit in openssl-web:

    commit 1bb9590bf583f21dc71b0adf83062f38e589644e
    Author: Rich Salz <rsalz at akamai.com>
    Date:   Mon Oct 24 18:03:32 2016 -0400

        Add policy docs from 2016 F2F, per vote.

So this is post 1.1.0 stuff

tjh> There should be none of the existing 50-<target> items and I also
tjh> think 90-team needs some work too - but that is separate from
tjh> actually splitting things out into the categories we have already
tjh> defined.

I disagree about the 50 group, as already mentioned above.

I find 90-team.conf *much* more questionable.  If it were me, I'd toss
the lot of what's in there, with the exception of the "dist" config
target (it's used by the "dist" target in Makefile).

tjh> Does anyone know what platform debug-erbridge is in 90-team?

Not a clue.  Most of the stuff in there can be traced back to what's
in pre-1.1.0 Configure.

I dug a bit, and found that it's this commit:

    commit d7f200779c190ba35cfa4dbd2a82587c938cd243
    Author:     Felix Laurie von Massenbach <felix at erbridge.co.uk>
    AuthorDate: Mon May 26 17:19:06 2014 +0100
    Commit:     Ben Laurie <ben at links.org>
    CommitDate: Sun Jun 1 15:31:26 2014 +0100

        Add a new target to Configure for me.

tjh> I also think you need a platform "owner" or "contact" tag ...

For primary stuff, that's us (i.e. The Project).
For secondary stuff, that's us (i.e. The Project).
For community stuff, that's the community (*).
For unknown stuff, I don't think we'll be able to, unless a config
target moves to a more active category.
For legacy stuff, I have some serious doubts...

(*) For community, I'm unsure about pinning this one a specific
person.  The commit message will already say (I hope) who provided it,
but that's a shot in the moment and doesn't mean that person is
willing to become The Responsible Person for that config target.  At
some later point in time, someone else may take up the gauntlet and
update some config target, but that's also spur of the moment.  This
is after all the nature of FOSS community development, and I don't
think pinning this on a single (or even a set of) person does anything
good for it.

So I think that in the end, while I can see the temptation for getting
a sense of control, I'd rather not go there.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/