laminas / technical-steering-committee

Laminas Project Technical Steering Committee organization and processes.

Laminas Technical Steering Committee

🇷🇺 Русским гражданам

Мы, участники Laminas, родились и живем в разных странах. У многих из нас есть друзья, родственники и коллеги как в России, так и в Украине. Некоторые из нас родились в России. Некоторые из нас живут в России. У некоторых бабушки и дедушки сражались с фашистами во Второй мировой войне. Здесь никто не поддерживает фашизм.

У одного из нас есть украинская родственница, которая спаслась из дома вместе с сыном. Поезд задержался из-за бомбежки на дороге впереди. У нас есть друзья, которые прячутся в бомбоубежищах. Мы с тревогой ждем весточки от них после воздушных налетов, которые беспорядочно наносят удары и попадают по больницам, школам, детским садам и домам. Мы не берем это из каких-либо СМИ. Мы наблюдаем это напрямую.

Вы доверяете нам достаточно, чтоб использовать наши программы, и мы просим вас довериться нам вновь. Мы нуждаемся в помощи. Выходите и протестуйте против этой бесполезной войны. Остановите кровопролитие. Скажите "Нет войне!"

🇺🇸 To Citizens of Russia

We at Laminas come from all over the world. Many of us have friends, family and colleagues in both Russia and Ukraine. Some of us were born in Russia. Some of us currently live in Russia. Some have grandparents who fought Nazis in World War II. Nobody here supports fascism.

One team member has a Ukrainian relative who fled her home with her son. The train was delayed due to bombing on the road ahead. We have friends who are hiding in bomb shelters. We anxiously follow up on them after the air raids, which indiscriminately fire at hospitals, schools, kindergartens and houses. We're not taking this from any media. These are our actual experiences.

You trust us enough to use our software. We ask that you trust us to say the truth on this. We need your help. Go out and protest this unnecessary war. Stop the bloodshed. Say "stop the war!"

This is the repository for the Laminas Project Technical Steering Committee.

This repository contains the following:

• List of current TSC members
• By-laws/processes
• Meeting agendas
• Voting records
• Accepted RFCs

technical-steering-committee's Issues

[NOMINATION][MAINTAINER]: Filippo Tessarotto – @Slamdunk for laminas-mail

Nomination

Filippo Tessarotto – @slamdunk has been involved in the Laminas / Zend Framework ecosystem since version 1 of the framework and additionally he is actively involved in different projects like ParaTest, PSR-7 Storage-less HTTP Sessions, lcobucci/jwt and some more.
He is already doing the work expected of a maintainer in terms of quality, design decisions and testing.

Therefore I nominate @Slamdunk as a maintainer for laminas-mail.

RFC: Proposal for GitHub Actions continuous integration workflow

We previously voted to migrate to GitHub Actions. Since then, Travis-CI has announced that OSS plans are limited to 10k minutes per month, and we have twice reached the limit by mid-month. On top of that, while we have requested an OSS exemption, and provided proof that we fit their criteria, the last word we had from them was that they were "revisiting the OSS policy".

Since we've now hit the limits a couple times, both Marco and myself have implemented CI via GitHub Actions on the following repositories:

• laminas/laminas-code
• laminas/laminas-cli
• laminas/laminas-eventmanager

At this time, I think I've hit on a workable solution; please see laminas/laminas-eventmanager#15 for details.

To get there:

• Pull the workflow file into the repo (I'll provide wget and/or curl commands in order to simplify this for those doing the work)
• Check the workflow against the current .travis.yml, and:
  • Set an alternate "stable PHP" (for non-unit test checks) in a config file if a version other than 7.4 should be used.
  • Set any php.ini settings in a config file, if needed.
  • Provide a list of additional extensions in a config file, if needed.
  • Provide a list of checks to perform via the config file, if additional or fewer checks are needed.
  • Create any new workflow files necessary if you need to do anything weird (such as test against different extension versions, etc.). This should be rare.
• Remove the .travis.yml (via git rm).
• Check-in the workflow file(s) and configuration file (if needed).
• Create a pull request.

---

Originally proposed solution (obsolete)

The solution uses a combination of the following actions:

• actions/checkout
• actions-cache
• shivammathur/setup-php

We then create one workflow file for each task/tool we want to run. Examples include:

• benchmarks.yml
• cs-checks.yml
• psalm-yml
• unit-tests.yml

A generic workflow file starts like the following:

name: "Name of workflow goes here"

on:
  pull_request:
    paths-ignore:
    - 'mkdocs.yml'
    - '*.md'
  push:
    paths-ignore:
    - 'mkdocs.yml'
    - '*.md'

jobs:
  run:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: 7.4
          extensions: mbstring, intl, readline
          ini-values: memory_limit=-1
          coverage: none
          tools: composer:v2, cs2pr

      - name: "Cache dependencies"
        uses: "actions/cache@v2"
        with:
          path: |
            ~/.composer/cache
            vendor
          key: "php-7.4-latest"
          restore-keys: "php-7.4-latest"

      - name: Install dependencies
        env:
          COMPOSER_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          composer install --no-interaction --no-progress --no-suggest
          composer show

From there, we add a step for the actual check being performed:

# CS checks
      - name: Run CS checks
        shell: bash
        run: "vendor/bin/phpcs -q --report=checkstyle | cs2pr"
# Benchmarks
      - name: Run benchmarks
        shell: bash
        run: "vendor/bin/phpbench run --revs=2 --iterations=2 --report=aggregate"
# Psalm
      - name: Perform static analysis
        run: "vendor/bin/psalm  --output-format=github --shepherd --stats"

For unit tests, we need a test matrix, and we need to vary things like composer arguments based on PHP version, whether or not to enable coverage, whether or not to upload coverage, etc.. This can be done by creating a matrix strategy, selective definition of matrix variables, and if step conditions and/or conditional environment variable declarations. As a full example:

jobs:
  run:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        php-version:
          - "7.3"
          - "7.4"
          - "8.0"
        deps-version:
          - "lowest"
          - "latest"
        include:
          - php-version: "7.4"
            deps-version: "latest"
            coverage: "xdebug"
          - php-version: "8.0"
            composer-args: "--no-interaction --no-progress --no-suggest --ignore-platform-reqs"

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php-version }}
          extensions: mbstring, intl, readline
          ini-values: memory_limit=-1
          coverage: ${{ matrix.coverage || 'none' }}
          tools: composer:v2

      - name: "Cache dependencies"
        uses: "actions/cache@v2"
        with:
          path: |
            ~/.composer/cache
            vendor
          key: "php-${{ matrix.php-version }}-${{ matrix.deps-version }}"
          restore-keys: "php-${{ matrix.php-version }}-${{ matrix.deps-version }}"

      - name: Install dependencies
        env:
          COVERAGE_DEPS: 'php-coveralls/php-coveralls'
          DEPS: ${{ matrix.deps-version }}
          COMPOSER_ARGS: ${{ matrix.composer-args || '--no-interaction --no-progress --no-suggest' }}
          COMPOSER_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          TEST_COVERAGE: ${{ matrix.coverage || '' }}
        shell: bash
        run: |
          composer install $COMPOSER_ARGS
          if [[ $DEPS == 'latest' ]]; then composer update $COMPOSER_ARGS ; fi
          if [[ $DEPS == 'lowest' ]]; then composer update --prefer-lowest --prefer-stable $COMPOSER_ARGS ; fi
          if [[ $TEST_COVERAGE != '' ]]; then composer require --dev $COMPOSER_ARGS $COVERAGE_DEPS ; fi
          composer show

      - name: Setup problem matcher for PHPUnit
        run: echo "::add-matcher${{ runner.tool_cache }}/phpunit.json"

      - name: Run unit tests
        env:
          TEST_COVERAGE: ${{ matrix.coverage || '' }}
        shell: bash
        run: |
          if [[ $TEST_COVERAGE != '' ]]; then composer test-coverage ; else composer test ; fi

      - name: Upload coverage
        if: matrix.coverage
        env:
          COVERALLS_REPO_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: "vendor/bin/php-coveralls -v"

Things to note in this example:

• The job matching a PHP 7.4 version with latest dependencies sets an additional matrix variable, "coverage", with the value "xdebug".
  • matrix.coverage is queried when determining whether or not to enable coverage in the setup-php action. Further, it is conditionally set to "none" if the value does not exist.
  • matrix.coverage is queried when setting a TEST_COVERAGE env variable when installing dependencies and running tests; it is conditionally set to an empty string if not present.
  • matrix.coverage is used as a conditional for the "Upload coverage" step; this means the step is skipped if the value is not set.
• Jobs matching a PHP 8.0 version set an additional matrix variable "composer-args", with a specific set of arguments to use for those versions.
  • The "Install dependencies" step checks to see if the value is set, and provides a default if not, assigning the value to the COMPOSER_ARGS env variable.
• The GITHUB_TOKEN secret is passed when installing dependencies and uploading coverage, and assigned to the appropriate env variable in each case. This prevents issues with hitting github API limits during installation, and allows us to upload to Coveralls.

A note on setup-php

This action is quite comprehensive in terms of allowing us to add extensions, provide INI settings, and use all the versions of PHP we need to test against; it also provides some tools (such as composer) out-of-the-box.

In the examples above, I am using the default PHP versions provided with the action, which may or may not be the latest versions released. There is a way to force the action to update to the latest version. However, when enabled, the "Setup PHP" step takes 1.5 - 2+ minutes per job (though jobs are run in parallel). When using the defaults, the step only takes 2s.
Since we are typically trying to favor speed of feedback, I argue we do not enable the flag to force updates.

How we get there

My plan is to create default versions of these workflow files, and place them in the repo-template repository. From there, I will create issues on all non-security-only repositories detailing the following:

• Pull the templates into the repo (I'll provide wget and/or curl commands in order to simplify this for those doing the work)
• Check the templates against the current .travis.yml, updating:
  • The test matrix, if needed.
  • The workflow files (to determine which version to run against, and/or whether or not the file is needed — if psalm integration is not present, or no benchmarks are needed, those can be omitted).
  • Additional conditional matrix variables/env variables, as needed.
• Remove the .travis.yml (via git rm).
• Check-in the workflow files.
• Create a pull request.

At that point, we can put out a call-to-action in the Slack and via Twitter to get folks to help, and those of us on the TSC can work on these as well.

RFC: Use Rector to provide "downgraded" releases

Early on when performing our updates to PHP 8.1, I got into a twitter discussion with Rector maintainers, and they pointed me to a blog post of theirs.

The idea is as follows:

• We would support ONE version of PHP at any given time in our release branch.
• After we create a release off that release branch:
  • We apply Rector rules to downgrade to the next lower minor version of PHP.
  • We emit a new tag and release, using the same version number, but with an additional octet representing the PHP version it targets. As an example, if we had just released 3.7.4 for PHP 8.0, we would tag the 7.4 version as 3.7.4.74.
  • We would continue the above steps back as far as we want to support.
• Users would pin like normal (e.g., ^3.7 or ~3.7.2), and would receive the version that works with their PHP version.

This change would require:

• Changes to automatic-releases
• Changes to how we handle release branches
• Changes to our security window policy

Regarding this latter, I would expect that the furthest PHP version backwards we would support would be the oldest still receiving security patches. The change to the security window would need to be how we identify how many minor versions back we go when doing a security patch; since we currently base it on whether or not the minimum supported PHP version is still getting security patches, this would clearly change going forwards, as it could lead to a huge list of affected branches.

Notes and tasks following marking of security-only packages

In preparation for marking packages as security-only and/or archiving them, I made the following notes, indicating follow-on tasks we need to track.

Packages depending on laminas-config

• laminas-i18n uses it in the AbstractFileLoader for reading from an INI file; maybe replace with hassankhan/config?
• laminas-validator uses it in tests; we can replace these with generic ArrayObject implementations.
• laminas-view uses it in tests; can likely be replaced with generic ArrayObject implementations.
• laminas-modulemanager returns config as a Config instance by default; cannot change this currently without a BC break.

Packages depending on laminas-console

• laminas-view: uses it in UrlIntegrationTest; can leave as-is, but should mark those tests deprecated
• laminas-modulemanager
  • mark Console(Usage|Banner)ProviderInterface as deprecated

Packages depending on laminas-crypt

• laminas-filter: Encrypt/BlockCipher depends on laminas-crypt
  • mark as deprecated
  • create new package delivering it, and mark as security-only
• laminas-authentication: uses Laminas\Crypt\Password\Apache and Laminas\Crypt\Utils::compareStrings
  • we can likely inline the apache password functionality, and deprecate the old functionality
  • we can likely inline the compareStrings functionality
• api-tools-oauth2: we can likely switch the implementation to use native PHP tools for bcrypt

Packages depending on laminas-db functionality

This one is kind of big.
We use it in laminas-feed, laminas-validator, laminas-session, laminas-log, laminas-paginator, laminas-authentication, api-tools-oauth, api-tools-content-validation, and api-tools.

We should probably come up witha comprehensive strategy for updating these packages, by one or more of:

• Deprecations of db-based functionality, and splitting those classes to different packages.
• Additions of doctrine/dbal functionality that mimics the laminas-db functionality

Original strategy:

• Look for packages of ours that consume laminas-db functionality.
• split dependent functionality into separate packages
  • mark these as security-only
• Mark laminas-db-consuming classes deprecated
  • indicate NO guarantees of working on PHP 8
• Remove any explicit deps on laminas-db
• Add new package as a suggested package

Packages depending on laminas-dom

• laminas-test uses laminas-dom for a number of DOM/XPath assertions.
  It's an implementation detail, so we can adapt to use symfony/dom-crawler.

Packages depending on laminas-http

This one is kind of big.
We use it heavily, as it forms the core of our MVC and by extension the laminas-api-tools; the various RPC servers; and numerous components that are tangentially related to the MVC (session, navigation, etc.).

We need a comprehensive strategy for updating these packages.

Notes:

• laminas-feed uses it in both the Reader and PubSubHubbub components.
  The former can likely be updated to use an alternative client by default in a new minor release, and the LaminasHttpClientDecorator can be marked deprecated.
  The latter uses it conditionally:

  • PubSubHubbub\Publisher uses it as an internal detail; this can be refactored.
  • PubSubHubbub stores an HTTP client as a singleton, but does not consume it itself (Subscriber consumes it, though).
  • Subscriber consumes the HTTP client, but does so as an implementation detail.
    We could adapt it to use an explicitly set client, and deprecate usage of the singleton client.
  • AbstractCallback stores and uses either a laminas-http response, or the package-specific HTTP response; this could be refactored to raise a deprecation notice when a laminas-http response is used.
  • CallbackInterface has methods for setting and retreiving the HTTP response, and assumes it is a PubSubHubbub\HttpResponse instance.

• laminas-validator sets a dependency on laminas-http... but does not actually use it.

• laminas-view stores a response in the Json helper, and, when invoked, sets the Content-Type header on it.
  (It also uses laminas-json to encode the JSON.)
  This can stay as-is.

• laminas-mvc clearly still uses it.

• laminas-session uses Laminas\Http\PhpEnvironment\RemoteAddress in the RemoteAddr validator to get the IP address.
  We can likely inline the class.

• laminas/laminas-psr7bridge bridges between it and PSR-7

• laminas-router clearly still uses it.

• laminas-authentication uses it in its Http authentication adapter.
  We should likely separate this one to its own package, and add a new one for PSR-7.
  Or just deprecate the damn package.

• laminas-test clearly still uses it.

• The various laminas-api-tools repositories still use it.

• laminas-navigation uses it for Uri-based pages.

• laminas-xmlrpc uses it for HTTP negotiation.

• laminas-json-server uses it for HTTP negotiation.

• laminas-recaptcha uses it for HTTP requests.

• laminas-twitter uses it for HTTP requests

Packages depending on laminas-json

These can all likely be inlined with usage of native JSON tools.

• laminas-view (the AbstractHtmlElement, JSON helper, JsonRenderer, and JsonModel)
• laminas-mvc (AbstractRestfulController)
• laminas-paginator (Paginator::toJson()
• api-tools-api-problem
• api-tools-content-negotiation
• laminas-json-server
• laminas-recaptcha (listed as a dependency, but never used)
• laminas-twitter

Packages depending on laminas-loader

Try and inline the required functionality where possible; otherwise, loosen up dependencies and start moving away from them.

• laminas-http (plugin class locator/loader)
• laminas-view (listed as a dependency, but never referenced)
• laminas-modulemanager (module autoloader, autoloader factory)
• laminas-diagnostics (listed as a dependency, but never referenced)
• api-tools (provides StandardAutoloader extension; not sure why)
• api-tools-admin (references StandardAutoloader in tests for retrieving autoloader config)

Packages depending on laminas-log

• laminas-view (used in one test; can likely be rewritten)
• laminas-test (listed as a dependency, but never referenced)
• laminas-navigation (listed as a dependency, but never referenced)
• api-tools-oauth2 (listed as a dependency, but never referenced)
• api-tools-doctrine (listed as a dependency, but never referenced)
• api-tools-doctrine-querybuilder (listed as a dependency, but never referenced)

Packages depending on laminas-math

• laminas-validator Used in CSRF validator for randomint - switch to native PHP functions
• laminas-captcha Used in AbstractWord for randomizing; switch to native PHP function
• laminas-xmlrpc Used in BigInteger for BigInt calculations; use native PHP functionality

Packages depending on laminas-oauth

• laminas-twitter (should likely refactor this to use a PSR-7 client)

Packages depending on laminas-serializer

This one is problematic due to usage in laminas-cache and laminas-hydrator; may need to come up with alternate plugins/strategies.

• api-tools-doctrine (listed as a dependency, but never referenced)
• api-tools-doctrine-querybuilder (listed as a dependency, but never referenced)
• api-tools-oauth2 (listed as a dependency, but never referenced)
• laminas-cache (serializers can be used as plugins)
• laminas-cache-storage-adapter-xcache (serializers can be used as plugins)
• laminas-hydrator (SerializableStrategy)
• laminas-test (listed as a dependency, but never referenced)
• laminas-view (listed as a dependency, but never referenced)

Packages depending on laminas-text

• laminas-form (listed as a dependency, but never referenced)
• laminas-captcha (used for Figlet text; can likely leave as-is and/or deprecate that captcha type)

Packages depending on laminas-uri

• api-tools-hal (used for validating URIs used as HREFs; can be refactored, as it is an internal detail)
• api-tools-rest (used during testing, as this component uses laminas-http)
• laminas-authentication (used for comparing request URI path to Authorization header URI path; used due to laminas-http)
• laminas-filter (used in UriNormalize filter; can be refactored, as it is in internal detail)
• laminas-http (used for URI representations)
• laminas-navigation (listed as a dependency, but never referenced)
• laminas-test (used for several URI assertions, as this is for the MVC, and thus uses laminas-http)
• laminas-twitter (due to usage of laminas-http)
• laminas-validator
  Uri validator is based on it; we should deprecate it, and provide an alternate implementation.
  Also, Sitemap\Loc validator uses it internally for validation of the sitemap URI; can be refactored.
• laminas-view (used internally in Sitemap helper to validate server URL; can be refactored)

Agenda: also ask to community with surveys

Hi, I'm reading your agenda, and as a long ZF user and contributor I would like to answer some question within a survey formula.

There are some usage feedbacks I could give that are not mirrored in how many time I download or contribute to a package, and looking to the target audience ZF tipically reached, I think a lot of it could give rich feedbacks too.

Add branch protection for release branches

See laminas/automatic-releases#126

Here's a sample script to batch apply the allow_force_pushes:false rule to every laminas repository.

It must be done by someone with admin privileges over all repositories.

#!/bin/bash
set -ex

cd "$(mktemp -d)" || exit 1

GITHUB_TOKEN=xxx

curl \
    -H "Accept: application/vnd.github.v3+json" \
    -H "Authorization: token $GITHUB_TOKEN" \
    https://api.github.com/orgs/laminas/repos \
    > repos.json

for repo in $(jq -c '{name:.[].name,default_branch:.[].default_branch}' repos.json); do
    repo_name="$(echo "$repo" | jq .name)"
    repo_default_branch="$(echo "$repo" | jq .default_branch)"

    curl \
        -X PUT \
        -H "Accept: application/vnd.github.v3+json" \
        -H "Authorization: token $GITHUB_TOKEN" \
        "https://api.github.com/repos/laminas/$repo_name/branches/$repo_default_branch/protection" \
        -d '{"branch":"*.*.x","allow_force_pushes":false}'

    break # To test it on the first repo
done

We should also write a note somewhere for new repositories.

UPDATE

If this is going to be discussed in the TSC agenda, it's worth discussion all the available features, see https://docs.github.com/en/github/administering-a-repository/about-protected-branches#about-branch-protection-settings

Mark security-only packages as `Abandoned` in packagist.org

Hi everybody, today we were trying to update our dependencies to psr/log:v3, but laminas-log conflicted because it only supports v1.
Ok, then I went to open a PR to extend its compatibility, but laminas/laminas-log#50 was already there.
I had to read all the comments, and then the README.md, and then 2020-08-03-TSC-Minutes.md to find out it's marked as security-only.

I would like to ask you to mark all the laminas packages currently voted as security-only as Abandoned in https://packagist.org/packages/laminas/: this aims to spread awareness of their status thanks to the built-in functionality of composer to pop yellow warnings for abadoned packages.

I am aware that, semantically, they are not really abandoned, but I think for the end user it's better than not having it marked so.

Update SECURITY.md with current security policy and a new way to report vulnerabilities

Our currently adopted security policy is to provide security fixes or backports to all previous releases as long as their minimum PHP version is in active or security maintenance.

This is not reflected in SECURITY.md in .github repositories or on website at https://getlaminas.org/security/

Recently GitHub provided beta feature to privately report security vulnerabilities using GitHub itself. This is now enabled on all our repositories. Consequently SECURITY.md needs to be updated with instructions on how to use it. See https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability

[NOMINATION][MAINTAINER]: arhimede, alexmerlin, MarioRadu, for maintaining laminas-api-tools

Nomination

I'm nominating the following people to maintain laminas-api-tools:

• arhimede https://github.com/arhimede
• alexmerlin https://github.com/alexmerlin
• MarioRadu https://github.com/MarioRadu

As the discussion started in this PR #134 , I would like to nominate a group of developers from DotKernel Organization in order to refactor and/or maintain laminas-api-tools and other new or current API related libraries.

• They have been working extensively with Laminas/Zend since Zend Framework 1.
• They have been contributing to various Zend Framework 1 libraries.
• Through their employment at Apidemia, they have been using Mezzio and Laminas tools from their inception, on a daily basis.
• They are up-to-date on API design best practices and guidelines.
• They have experience in understanding and satisfying the API requirements of clients through face-to-face interactions.
• They have an interest in fixing issues and implementing features, especially in the components which they use in their assigned projects, and are willing to invest time in doing so.

`laminas/laminas-zendframework-bridge` in skeleton applications

I wonder if we should add the replace keyword for the laminas/laminas-zendframework-bridge in the skeleton app.

{
    "replace": {
        "laminas/laminas-zendframework-bridge": "*"
    }
}

Imho, no one should create a new laminas package along with modules which are still not migrated until now,
So the bridge won't have any meaning. This is also the root cause on why we're facing this issue.

Maybe something we want to consider in the TSC tomorrow. Gonna add an agenda item.

Originally posted by @boesing in laminas/laminas-test#38 (comment)

Repository description contains a typo

-Laminas Project Technical Steering Committee organization and proccesses.
+Laminas Project Technical Steering Committee organization and processes.

RFC: How to finalize the decision to mark security-only repositories

We voted in August to mark a number of repositories "security-only".

The problem: we never did. Worse, we had no plan for what that process would look like, other than some vague wording on the repository README.

As the months roll on, this gets more problematic, as we are ignoring PRs in those repositories. (This was made even worse by the fact that we opened the PHP 8 and Psalm issues on them as well!)

We need a plan.

During our meeting in July, the following were all brought up as viable options/actions, some of which might be used in combination with others:

• Adding a note to the repository README.md indicating security-only status.
• Labeling them (via repository topics)
• Sharing a set of issue and PR templates that message the "security-only" status, and applying these during manual triage.
• Using a bot or GitHub Action to auto-close any issues/PRs opened against them (likely with the template developed above).

What we did NOT discuss was:

• Do these get the automatic-releases automation and/or the switch to release branches as part of the change?
• What do we do about existing open issues and pull requests?
• How exactly should the verbiage detailing "security-only" status for the README and/or issues read? Should it provide a link to the "nominate maintainer" issue form?
• What bots/GHAs exist that could do auto-closure?

Current activity

Component	Issues	Patches
laminas-barcode	3	1
laminas-config	6	1
laminas/laminas-config-aggregator-modulemanager	1	0
laminas/laminas-console	11	1
laminas/laminas-crypt	6	3
laminas/laminas-db	128	14
laminas/laminas-dom	7	2
laminas/laminas-file	3	1
laminas/laminas-http	28	0
laminas/laminas-json	7	1
laminas/laminas-loader	3	1
laminas/laminas-log	9	1
laminas/laminas-mail	60	5
laminas/laminas-math	2	1
laminas/laminas-memory	2	0
laminas/laminas-mime	10	2
laminas/laminas-mvc-console	4	0
laminas/laminas-oauth	7	0
laminas/laminas-progressbar	5	0
laminas/laminas-serializer	5	2
laminas/laminas-servicemanager-di	2	0
laminas/laminas-soap	23	1
laminas/laminas-tag	2	0
laminas/laminas-text	1	0
laminas/laminas-uri	7	0
laminas/laminas-xml	1	0
laminas/laminas-xml2json	3	0

The majority of the repos we voted to mark security-only have a handful of issues and 0-3 pull requests; 2 issues in each are generally the PHP 8 and Psalm support issues created for Hacktoberfest.
A few, however, have significant amounts of activity:

• laminas-console
• laminas-crypt
• laminas-db
• laminas-http
• laminas-mail
• laminas-mime
• laminas-soap

We have messaged for many years that zend-console/laminas-console is dead, and with laminas-cli now in good condition, I have zero problem directing users to that solution. Similarly for laminas-crypt, the cryptography tools in PHP have gained great capabilities, and, more importantly, simple interfaces, making it easy to direct users to those tools. All open issues except 4 issued against laminas-http were migrated from the original zend-http repo; assuming the plan for laminas-mvc v4 is to use PSR-7, we can likely write these off without too much fuss. The same is true of laminas-soap (3 new issues since migration, 2 of which were the PHP 8/Psalm issues).

The remaining are more problematic.

laminas-db only has 11 new issues since the migration, but has 14 PRs currently open. On top of that, prior to the migration, there had been an RFC for splitting out adapters into their own packages, and some of that work is in the dev-3.0.0 branch. From what I can tell, most of the patches are not security-sensitive, but many are ones that pre-date the decision to mark the repo security-only, and many are fixing outstanding problems.

For laminas-mail, we have a similar scenario: only 11 new issues since migration, but all current patches were submitted after we made the security-only decision. However, we've outlined a future 2.13.0 release, and done 3 releases since we made the security-only decision. The related laminas-mime component only has one user-opened issue since migration, and one patch predates the security-only decision.

Proposal

I propose the following:

• We drop an addition to the README.md file on the current release branch of each of the repositories, reading:

  This package is considered feature-complete, and is now in **security-only** maintenance mode.
  If you have a security issue, please [follow our security reporting guidelines](https://getlaminas.org/security/).
  If you wish to take on the role of maintainer, please [nominate yourself](https://github.com/laminas/technical-steering-committee/issues/new?assignees=&labels=Nomination&template=Maintainer_Nomination.md&title=%5BNOMINATION%5D%5BMAINTAINER%5D%3A+%7Bname+of+person+being+nominated%7D)

  Where an alternative package exists, we will append the following verbiage to the message:

  If you are looking for an actively maintained package alternative, we recommend [package name](link to package).

• Close all open PRs and issues with a comment containing the text addtions made for the README.md.

• Add the issue-auto-closer github action to the repository workflow. We can set the issue-pattern to match any text. The issue-close-message text can be the same as in the README.md additions.

• We add a repository topic of "security-updates-only", which will allow us to provide a search link to give users a reference of which repos we no longer support.

What about the laminas-db package?

We don't want to maintain a database package. There are too many databases to test against, and it's like playing whack-a-mole ensuring everything works across all databases we would want to support.

We should just recommend doctrine/dbal.

What about laminas-mail and laminas-mime?

We have an active contributor who I will not name, but who is periodically sending in patches to address bugs and issues on these two repositories. At first glance, they would appear to be an ideal candidate to recruit as a maintainer.

However, I have reviewed quite a number of their patches in the past, and while many are fine, there have been a number of cases where:

• the patch had no tests
• the patch broke existing functionality

and their typical response has been a shrug and an expectation we'd either merge as-is, or correct things for them.

I see the following options:

• We just go ahead and treat this like the other repos we voted to make security only, and be done.
• We invite the contributor to be a maintainer, with the caveat that for the first "X" months, we have an integration in place that requires a review from a TSC member on all pull requests before a merge can be done.

The problem with the latter approach is that we will still be spending time on the components for however long "X" months is, when our plan was to drop support so we wouldn't need to spend more time on them.

My recommendation: mail protocols are notoriously painful, and we likely shouldn't even entertain the idea of getting a maintainer for our libraries. I suggest we direct users to one or all of the following:

• For users needing mail storage access/mail reading capabilities:
  • php-imap/php-imap
  • zbateson/mail-mime-parser
  • ddeboer/imap
• For users needing the ability to send email:
  • Swift Mailer
  • Nette Mail
  • Symfony Mailer

How to proceed

I'll call a vote starting on Monday, 2021-01-11; once the vote is complete, assuming it passes, I'll start enacting the above immediately.

Add issue template for inclusion of external projects into the `laminas/` project

Summary

As discussed during today's TSC meeting, we need an issue template to allow people to request inclusion of third-party projects in the laminas/* project, and to add the maintainers of those projects as TSC members.

@Ocramius will provide the initial template PR.

RFC: Standardise Psalm Configuration

Thanks to @boesing, I recently discovered some psalm configuration options that'll be potentially helpful to improving code quality.

I'd like to start discussion about which of those options we should switch on or off by default for Laminas and Mezzio projects so that we can define a standard configuration.

Once a standard has been decided, it should be applied everywhere with an expanded baseline so that new code will need to pass a stricter set of requirements as enforced by CI.

To start discussion off, I'm thinking something like this:

<?xml version="1.0"?>
<psalm
    errorLevel="1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="https://getpsalm.org/schema/config"
    xsi:schemaLocation="https://getpsalm.org/schema/config vendor/vimeo/psalm/config.xsd"
    errorBaseline="psalm-baseline.xml"
    ignoreInternalFunctionFalseReturn="false"
    ignoreInternalFunctionNullReturn="false"
    allowInternalNamedArgumentCalls="false"
    allowNamedArgumentCalls="false"
    strictBinaryOperands="true"
    disableSuppressAll="true"
    memoizeMethodCallResults="true"
    checkForThrowsDocblock="false"
    findUnusedVariablesAndParams="true"
    findUnusedCode="false"
    findUnusedPsalmSuppress="true"
>
    <projectFiles>
        <directory name="src"/>
        <directory name="test"/>
        <ignoreFiles>
            <directory name="vendor"/>
        </ignoreFiles>
    </projectFiles>

    <plugins>
        <pluginClass class="Psalm\PhpUnitPlugin\Plugin"/>
    </plugins>
</psalm>

Reference: https://psalm.dev/docs/running_psalm/configuration/

Perhaps, once decided, a template can be stored in the Laminas .github organisation repo?

RFC: We need a mail provider

Q | A

• | -
  RFC | Yes

I've been taking care of domain registration fees since before we launched. The provider I use for getlaminas.org allows me to create one email forwarding address as part of the fee, but that's the limit; beyond that, and it's $1 or $2 per month per address. So far, we've only had to use one ([email protected]), but with the upcoming commercial vendor/support provider program, we will need another so that we can receive logos and receipts from these supporters. Additionally, it will give us a channel to communicate with them going forwards.

I've done some research into mail providers, and these are the top contenders, in no particular order:

Provider	Cost (if known)	Features/Comments
Gmail	$6/month/user	We all know this one.
Groups.io	$20/month	It's more of a group collab option; I'm not 100% sure it can accept email for a domain; if it can, that would be in the $200/month enterprise option (we can likely get a 50% discount on both plans as we are LF members, though)
Protonmail	5EUR/month	Highly secure, but we'd be limited to 5 addresses, and no "catch-all" email for the domain.
Zoho	$1/month/user	There is a free tier that accomodates up to 5 addresses, but also disables SMTP and IMAP support.

We appear to have around a dozen people currently donating $10 or more monthly, and have accumlated several thousand dollars in our account, so we have funds; that said, I think we'd all rather go cheap on things like infrastructure so that we can get to a point where we can either fund targeted projects or part-time personnel.

My inclination is to go with the Zoho paid plan, and start with 2 addresses (our security address, and a general catch-all address); having the paid plan gets us IMAP and SMTP, which in turn ensures nobody needs to actively check so long as they have an email client subscribing to the addresses. I doubt we'll need more than a handful of addresses unless we decide we want the entire TSC and/or all maintainers to have getlaminas.org addresses; if that happens, we can revisit the decision.

[NOMINATION][MAINTAINER]: Filippo Tessarotto – @Slamdunk for laminas-form

Nomination

Filippo Tessarotto – @slamdunk has been involved in the Laminas / Zend Framework ecosystem since version 1 of the framework and additionally he is actively involved in different projects like ParaTest, PSR-7 Storage-less HTTP Sessions, lcobucci/jwt and some more.
He is already doing the work expected of a maintainer in terms of quality, design decisions and testing.

Therefore I nominate @Slamdunk as a maintainer for laminas-form.

[NOMINATION][MAINTAINER]: MassiCav, clarphp, slaff-at-zend, for maintaining laminas-db

Nomination

I nominate the following people to maintain laminas-db:

• Massi Cavicchioli (@MassiCav)
• Clark Everetts (@clarkphp)
• Slavey Karadzhov (@slaff-at-zend)
• myself

Each of these individuals do regular client-facing work through their employment at Zend by Perforce that requires experience and expertise with a variety of RDBMS platforms, including the various enterprise-facing RDBMS platforms supported by laminas-db (e.g., DB2, OCI8). Each also has a track-record of high-quality code, and I will be available to train them in Laminas QA standards. They have a vested interest in ensuring that fixes and features continue to move forward in the component, due to their customer list, and are willing to invest time in doing so.

[PROPOSAL] New laminas-servicemanager-inspector package

Preface

It's no doubt that static analysis comes in handy in a variety of use cases nowadays.

Both ReflectionBasedAbstractFactory & AutowireFactory are quite well-demanded, even though its overall configuration is quite error prone, especially if one doesn't favour the AoT.

Problem

There are a few runtime defects possible now:

• Circular dependency
• Cyclic alias
• Missing factory
• Factory autoload failure
• Unresolvable service/scalar
• Scalar type/name mismatch
• Many other scenarios of misconfiguration

Solution

Hereby I'm offering a new package, which is capable of addressing all the issues specified above statically.
Basically it's just a tool that uses $config['dependencies'] to tell us whether it's all good or not (with certain degree of confidence). It will also scan AST for all ContainerInterface::get() calls, to see whether all of them can be satisfied.

WIP

Scope of use

It would benefit current end-users of laminas-servicemanager, no matter if used with laminas-di/AoT or not.
Suitable for both laminas/mezzio-based applications.

As @Xerkus and @tux-rampage suggested it can be used by servicemanager as a dev dependency.

Maintaining

I'll be able to maintain the package once it's approved.

RFC: Introduce a new package to decouple View from MVC

laminas-view is currently coupled to laminas-mvc.

As part of the effort to evolve and improve laminas-view, it would be useful to extract the code and features that are only relevant to laminas-mvc into a separate package named something like laminas-mvc-view in a similar vein to mezzio-laminasviewrenderer with the namespace Laminas\Mvc\View.

I have made a start on the package at gsteel/laminas-mvc-view.

Currently, this package contains ServerUrl and Url view helpers that provide BC with their counterparts in laminas-view. The goal would be to eventually move/replace all of the MVC-specific functionality in this package:

• Any other view helpers specific to MVC
• The ViewEvent and the main View class/entrypoint
• The RenderingStrategy framework

Once the package has a stable release, the plan would be to deprecate all the relevant classes in laminas-view in a minor release of the 2.x series, removing them in 3.0.

A minor release of laminas-mvc itself might be of benefit as there is opportunity to move code in the Laminas\Mvc\View namespace to the proposed package.

Whilst this RFC is only relevant to the MVC related code, there are further opportunities to de-couple laminas-view from laminas-navigation and laminas-feed.

I believe that as navigation in inherently "view related", it would be best to move all of the navigation related helpers to the navigation component making view a dependency of navigation.

The Feed renderer and rendering strategy might be co-located with the proposed package, moved to a standalone package or to laminas-feed.

References:

• Discussion in laminas/laminas-view#160
• laminas/laminas-view#149