Record my vote on 11577
-1 for breaking compliance.

Record my vote on 1.1.1 merge process
0 It depends on the context.

I think that the only rules that should apply are:
Changes should not be merged to 1.1.1 before master commit is merged.
1.1.1 PR changes in most cases should be linked to the master commit (or a reason given why there is no master).

record Mark's vote in the 1.1.1 merge vote

record 1.1.1 merge process vote

Record Nicola's vote about cherry-pick

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.

Personal notes:
  - 1.1.1 and master test suites have diverged significantly, and there
    have been recently merges to 1.1.1 that caused the 1.1.1-stable
    branch to fail tests that would have been caught if a dedicated PR
    with a full CI run was used instead of the current cherry-picking
    approach.
  - I agree that, sometimes, doing a full PR for backports, and then
    waiting for the full CI to run, and then for the 24h grace period,
    might seem like overcomplicating and delaying things, but at the
    same time it seems worth it to have less "mistakes" on the stable
    LTS branch.

Start cherry-pick vote

Record my vote on 11577

t8m: record my vote on 'Accept and merge #11577'

The PR as is is breaking the standards compliance, so I vote -1.

Record Nicola's vote about #11577

topic: Accept and merge #11577.
comment: #11577 reduces the maximum length of TLS labels.
         It also breaks standards compliance.

Personal notes:
 - My vote is against the current implementation of #11577, which does
   break standard compliance.
   I wouldn't be against an hybrid solution like Matt's at
   https://github.com/openssl/openssl/pull/11577#issuecomment-629418584
   but I am not capable of saying if the added complexity would be
   balanced by the effective benefits for platforms with limited stack
   resources.
 - My vote here is only on the matter of breaking standards compliance.
   It has nothing to do with the other concerns raised alongside the
   technical discussion in #11577: as I see it, those matters are not
   within the OTC responsibility.

Richard's vote

Covering:

topic: Accept and merge #11577.

Vote about #11577

Record Tim's vote on for Keep FIPS_mode() as emulated

Record votes for Keep FIPS_mode() as emulated

And close the vote. It did not pass.

register vote

Add vote (-1) for Keep FIPS_mode()

add vote for keeping FIPS_mode() emulated call

Record and close a vote

record current vote status

add vote

Add header comment to voting file

Add Shane to voting template

Add a voting template