<div dir="auto">We made and agreed to a set of categories and we should use what we agreed to - rather than something else.<div dir="auto"><br></div><div dir="auto">Introducing different terms I think does not make sense. Using the ones we have defined does.<br><div dir="auto"><br></div><div dir="auto">Tim.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 Jan. 2018 7:57 pm, "Richard Levitte" <<a href="mailto:levitte@openssl.org">levitte@openssl.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In message <<a href="mailto:CAHEJ-S6JWVUFHMpjZQOguOqGRdQD792eyO68_n_Px90hM6KKRA@mail.gmail.com">CAHEJ-<wbr>S6JWVUFHMpjZQOguOqGRdQD792eyO6<wbr>8_n_Px90hM6KKRA@mail.gmail.com</a><wbr>> on Tue, 9 Jan 2018 17:49:36 +1000, Tim Hudson <<a href="mailto:tjh@cryptsoft.com">tjh@cryptsoft.com</a>> said:<br>
<br>
tjh> Given the discussion on PR#5035 it is time to split 10-main.conf into three groups to match the<br>
tjh> platform policy and roadmap in my view.<br>
tjh><br>
tjh> 10-primary<br>
tjh> 20-secondary<br>
tjh> 30-community<br>
tjh> 40-unknown<br>
tjh> 50-deprecated<br>
<br>
Arbitrary numbers will always be arbitrary. We've already started<br>
with new community contributed config targets in the 50 group, why<br>
change that?<br>
<br>
Also, there's no real reason to have one big monolithic file per<br>
group. As you can notice from said 50 group, we've already divided<br>
them in smaller things... per platform family of sorts, maybe?<br>
<br>
So may I suggest that we use the groups 10-49 for stuff "known by us"<br>
(i.e. primary and secondary), 50-89 for "not so known by us"<br>
(i.e. community provided, unknown and deprecated), leaving 00-09 for<br>
base templates (*) and 90-99 for "personal" (i.e. team stuff we choose<br>
to share as well as simply leaving space for those who want to<br>
maintain their own inside their copy of our source)?<br>
<br>
Finally, I think we used the term "legacy" rather than "deprecated" at<br>
some point. Would you mind "legacy"?<br>
<br>
tjh> Most of the current 10-main should move into 40-unknown - that is<br>
tjh> the reality of our actual context.<br>
<br>
Agreed.<br>
<br>
tjh> See <a href="https://www.openssl.org/policies/platformpolicy.html" rel="noreferrer" target="_blank">https://www.openssl.org/<wbr>policies/platformpolicy.html</a> for the<br>
tjh> policy and <a href="https://www.openssl.org/policies/roadmap.html" rel="noreferrer" target="_blank">https://www.openssl.org/<wbr>policies/roadmap.html</a> where we<br>
tjh> stated that this would be completed by the next feature release<br>
tjh> (i.e. I think that was 1.1.0 at the time but even if we looked<br>
tjh> from the point of view of "now" that would be 1.1.1). We missed<br>
tjh> that timeline.<br>
<br>
The statements about next feature release were added as off this<br>
commit in openssl-web:<br>
<br>
commit 1bb9590bf583f21dc71b0adf83062f<wbr>38e589644e<br>
Author: Rich Salz <<a href="mailto:rsalz@akamai.com">rsalz@akamai.com</a>><br>
Date: Mon Oct 24 18:03:32 2016 -0400<br>
<br>
Add policy docs from 2016 F2F, per vote.<br>
<br>
So this is post 1.1.0 stuff<br>
<br>
tjh> There should be none of the existing 50-<target> items and I also<br>
tjh> think 90-team needs some work too - but that is separate from<br>
tjh> actually splitting things out into the categories we have already<br>
tjh> defined.<br>
<br>
I disagree about the 50 group, as already mentioned above.<br>
<br>
I find 90-team.conf *much* more questionable. If it were me, I'd toss<br>
the lot of what's in there, with the exception of the "dist" config<br>
target (it's used by the "dist" target in Makefile).<br>
<br>
tjh> Does anyone know what platform debug-erbridge is in 90-team?<br>
<br>
Not a clue. Most of the stuff in there can be traced back to what's<br>
in pre-1.1.0 Configure.<br>
<br>
I dug a bit, and found that it's this commit:<br>
<br>
commit d7f200779c190ba35cfa4dbd2a8258<wbr>7c938cd243<br>
Author: Felix Laurie von Massenbach <<a href="mailto:felix@erbridge.co.uk">felix@erbridge.co.uk</a>><br>
AuthorDate: Mon May 26 17:19:06 2014 +0100<br>
Commit: Ben Laurie <<a href="mailto:ben@links.org">ben@links.org</a>><br>
CommitDate: Sun Jun 1 15:31:26 2014 +0100<br>
<br>
Add a new target to Configure for me.<br>
<br>
tjh> I also think you need a platform "owner" or "contact" tag ...<br>
<br>
For primary stuff, that's us (i.e. The Project).<br>
For secondary stuff, that's us (i.e. The Project).<br>
For community stuff, that's the community (*).<br>
For unknown stuff, I don't think we'll be able to, unless a config<br>
target moves to a more active category.<br>
For legacy stuff, I have some serious doubts...<br>
<br>
(*) For community, I'm unsure about pinning this one a specific<br>
person. The commit message will already say (I hope) who provided it,<br>
but that's a shot in the moment and doesn't mean that person is<br>
willing to become The Responsible Person for that config target. At<br>
some later point in time, someone else may take up the gauntlet and<br>
update some config target, but that's also spur of the moment. This<br>
is after all the nature of FOSS community development, and I don't<br>
think pinning this on a single (or even a set of) person does anything<br>
good for it.<br>
<br>
So I think that in the end, while I can see the temptation for getting<br>
a sense of control, I'd rather not go there.<br>
<br>
Cheers,<br>
Richard<br>
<br>
--<br>
Richard Levitte <a href="mailto:levitte@openssl.org">levitte@openssl.org</a><br>
OpenSSL Project <a href="http://www.openssl.org/~levitte/" rel="noreferrer" target="_blank">http://www.openssl.org/~<wbr>levitte/</a><br>
______________________________<wbr>_________________<br>
openssl-project mailing list<br>
<a href="mailto:openssl-project@openssl.org">openssl-project@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-project" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-<wbr>project</a><br>
</blockquote></div></div>