# A record of formal votes in reverse chronological order. # # To vote, add one of the following entries next to your name: # # [+1] I vote in favour of the proposal # [ 0] I abstain from the vote # [-1] I vote against the proposal # # If you are abstaining, you can indicate a tendency as follows: # # [+0] I abstain but with a slight lean towards a vote in favour # [ 0] I abstain with no stated preference # [-0] I abstain but with a slight lean towards a vote against # # A template for voting (alphabetical by surname) follows. ---------------- topic: . Proposed by . Public: yes opened: 2020-mm-dd closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [ ] Mark [ ] Pauli [ ] Viktor [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [ ] Kurt [ ] Matthias [ ] Nicola [ ] ---------------- topic: Accept the OTC voting policy as defined: The proposer of a vote is ultimately responsible for updating the votes.txt file in the repository. Outside of a face to face meeting, voters MUST reply to the vote email indicating their preference and optionally their reasoning. Voters MAY update the votes.txt file in addition. The proposed vote text SHOULD be raised for discussion before calling the vote. Public votes MUST be called on the project list, not the OTC list and the subject MUST begin with “VOTE:”. Private votes MUST be called on the OTC list with “PRIVATE VOTE:” beginning subject. Proposed by Matthias St. Pierre (on behalf of the OTC) Public: yes opened: 2020-09-28 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [+1] Mark [+1] Pauli [+1] Viktor [ ] Tim [+1] Richard [+1] Shane [+1] Tomas [+1] Kurt [ ] Matthias [+1] Nicola [+1] ---------------- topic: Adopt the coding style policy on function arguments as shown in chapter 6.1 of web PR 194 (commit f37f8a9000) Proposed by Matt Caswell Public: yes opened: 2020-09-16 closed: 2020-09-21 accepted: no (for: 2, against: 5, abstained: 2, not voted: 2) Matt [+1] Mark [ 0] Pauli [-1] Viktor [ ] Tim [-1] Richard [-1] Shane [-1] Tomas [+1] Kurt [-1] Matthias [+0] Nicola [ ] ---------------- topic: Adopt the coding style policy on extending existing functions as shown in chapter 6.2 of web PR 194 (commit f37f8a9000) Proposed by Matt Caswell Public: yes opened: 2020-09-16 closed: 2020-09-21 accepted: yes (for: 5, against: 3, abstained: 2, not voted: 1) Matt [+1] Mark [ 0] Pauli [+1] # Vote changed 2020-09-21 Viktor [ ] Tim [-1] Richard [+1] Shane [+1] Tomas [+1] Kurt [-1] Matthias [+0] Nicola [-1] ---------------- topic: The performance improvements provided in PR11188 should be considered a bug fix and therefore acceptable for backport to 1.1.1 Proposed by Matt Caswell Public: yes opened: 2020-08-27 closed: 2020-09-10 accepted: no (for: 0, against: 8, abstained: 3, not voted: 0) Matt [-1] Mark [ 0] Pauli [-0] Viktor [-1] Tim [-1] Richard [-1] Shane [-1] Tomas [-1] Kurt [-1] Matthias [-0] Nicola [-1] ---------------- topic: Rename OSSL_SERIALIZER / OSSL_DESERIALIZER to OSSL_ENCODER / OSSL_DECODER The rationale is that it makes things easier on programmers (encode / decode is easier to write than serialize / deserialize), and also avoids disputes on what is and isn't serialization. Associated issues and PRs: #12455, #12659 and #12660 Proposed by Richard Public: yes opened: 2020-08-18 closed: 2020-08-20 accepted: yes (for: 5, against: 1, abstained: 4, not voted: 1) Matt [ 0] Mark [ 0] Pauli [+1] Viktor [ ] Tim [-1] Richard [+1] Shane [-0] # Shane's vote was actually --0 Tomas [+1] Kurt [ 0] Matthias [+1] Nicola [+1] ---------------- topic: Rename OPENSSL_CTX to OSSL_LIB_CTX (as proposed by pull request #12621) The main rationale behind this change is consistency, because many of the new OpenSSL 3.0 types have an OSSL_ prefix, and OPENSSL_CTX is a notable exception. More details can be found in the description and thread of pull request #12621. There was a discussion on openssl-committers ('Rename OPENSSL_CTX to OSSL_WHAT?') and an initial poll on doodle about the favourite replacements for OPENSSL_CTX (https://doodle.com/poll/drku9ziwvkp6tw25). Proposed by Matthias St. Pierre Public: yes opened: 2020-08-18 closed: 2020-08-20 accepted: yes (for: 5, against: 0, abstained: 4, not voted: 2) Matt [ 0] Mark [ ] Pauli [+1] Viktor [ ] Tim [-0] Richard [-0] Shane [+1] Tomas [+1] Kurt [ 0] Matthias [+1] Nicola [+1] ---------------- topic: For change requests which target both the master and the OpenSSL_1_1_1-stable branch, the following procedure should be followed: - First, a pull request needs to be opened against the master branch for discussion. Only after that pull request has received the necessary amount of approvals, a separate pull request can be opened against the OpenSSL_1_1_1-stable branch. - A separate pull request against the OpenSSL_1_1_1-stable branch is required. This holds - contrary to common practice - even if the change can be cherry-picked without conflicts from the master branch. The only exception from this rule are changes which are considered 'CLA: trivial', like e.g. typographical fixes. Proposed by Matt Caswell Public: yes opened: 2020-06-02 closed: 2020-06-16 accepted: no (for: 4, against: 4, abstained: 3, not voted: 0) Matt [ 0] Mark [ 0] Pauli [-1] Viktor [+1] Tim [+1] Richard [-1] Shane [ 0] Tomas [-1] Kurt [-1] Matthias [+1] Nicola [+1] ---------------- topic: Accept and merge #11577. comment: #11577 reduces the maximum length of TLS labels. It also breaks standards compliance. Proposed by Paul. Public: yes opened: 2020-06-02 closed: 2020-06-03 accepted: no (for: 0, against: 9, abstained: 1, not voted: 1) Matt [-1] Mark [-1] Pauli [-1] Viktor [ ] Tim [-1] Richard [-1] Shane [-1] Tomas [-1] Kurt [-1] # 2020-06-09 Matthias [ 0] Nicola [-1] ---------------- topic: Keep FIPS_mode() as emulated by EVP_default_properties_is_fips_enabled(NULL) Proposed by Tomas Mraz Public: yes opened: 2020-04-09 closed: 2020-04-27 accepted: no (for: 2, against: 5, abstained: 3, not voted: 1) Matt [+1] Mark [ 0] Pauli [-1] Viktor [ ] Tim [-1] Richard [ 0] Shane [-1] Tomas [+1] Kurt [ 0] Matthias [-1] Nicola [-1] ---------------- topic: approve PR#8300 statem: fix the alert sent for too large messages Proposed by Tim Hudson Public: yes opened: 2020-01-16 closed: 2020-01-30 accepted: no (for: 1, against: 4, abstained: 6, not voted: 0) Matt [-1] Mark [ 0] Pauli [-1] Viktor [-1] Tim [+1] Richard [ 0] Shane [-0] Tomas [+0] Kurt [ 0] Matthias [-1] Nicola [ 0]