[openssl-project] platforms

Tue Jan 9 10:06:10 UTC 2018

We made and agreed to a set of categories and we should use what we agreed
to - rather than something else.

Introducing different terms I think does not make sense. Using the ones we
have defined does.

Tim.

On 9 Jan. 2018 7:57 pm, "Richard Levitte" <levitte at openssl.org> wrote:

> In message <CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO6
> 8_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/
> _______________________________________________
> 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/20180109/d785354f/attachment-0001.html>