Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130461
Content-Type: multipart/alternative;
 boundary="------------SuajdzusSFB8O8lc79M5Me3W"
Message-ID: <55f527e7-1d86-4d41-9abc-ff646c736454@gmail.com>
Date: Thu, 26 Mar 2026 17:52:53 +0100
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: internals@lists.php.net
Subject: [PHP-DEV] Re: [RFC] php-community: a faster-moving, community-driven PHP.
Content-Language: fr
From: pierstoval@gmail.com ("Alex \"Pierstoval\" Rock")

This is a multi-part message in MIME format.
--------------SuajdzusSFB8O8lc79M5Me3W
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

 > You cannot convince companies who are actively looking for 
alternatives to
 > PHP due to the lack of core, modern features like async, generics to 
invest
 > in PHP, so that maybe (more likely no than yes, as proven) in the future
 > internals may accept RFCs (financed by the PHPF or not), bringing 
async and
 > generics into PHP.

You might be mixing things a little bit here: companies that use PHP 
must be convinced that donating to the PHPF will help them. But these 
can be /any/ kinds of companies. Not all of them are actively looking 
for alternatives to PHP. I don't know how you work for, nor your past 
experience, but I know for a fact that there are *lots* of companies 
that are actually very happy of the state of PHP still being maintained, 
compared to actually unmaintained tech that sometimes is younger than 
PHP. All these are different subjects.

The point is: the PHPF needs funding, from anyone, because without it, 
PHP will die, and the millions of apps worldwide that use PHP will be at 
risk, and their users with it, which would cause a lot of unimaginable 
problems.


 > You first need to have a working, proven track record of leadership 
capable
 > of merging new features into PHP.

What you call a "leadership capable of merging new features into PHP" is 
the actual work of the core maintainers, the PHP release managers, and 
the volunteering community that accepts to read the internals, RFCs, 
PRs, etc.
This is the *current way* of doing things, and I don't understand why 
you make this comment about "You first need to (...)" while it's already 
the case right now, and has been for many years now.


 > Internals currently has exactly the opposite track record: this has to
 > change in order for both PHP and the PHPF to succeed.

Opposite to what? Merging new features to PHP? If you go to the PHP: 
Appendices <https://www.php.net/manual/en/appendices.php> page on 
php.net, there are a lot of "Migrating from (...)" pages that contain 
all the new features merged in PHP in each minor and major versions. 
Reading them for *any* version shows that there are a *lot* of new 
features on all new PHP versions, and actually way more than what is 
presented in the /"What's new in PHP X.Y?"/ blog posts that we see 
popping out on the web every year.
Your comment is just false, internals *do* have a track record of 
working successfully in adding new features to PHP.

--------------SuajdzusSFB8O8lc79M5Me3W
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    &gt; You cannot convince companies who are actively looking for
    alternatives to
    <br>
    &gt; PHP due to the lack of core, modern features like async,
    generics to invest
    <br>
    &gt; in PHP, so that maybe (more likely no than yes, as proven) in
    the future
    <br>
    &gt; internals may accept RFCs (financed by the PHPF or not),
    bringing async and
    <br>
    &gt; generics into PHP.
    <br>
    <p>You might be mixing things a little bit here: companies that use
      PHP must be convinced that donating to the PHPF will help them.
      But these can be <i>any</i> kinds of companies. Not all of them
      are actively looking for alternatives to PHP. I don't know how you
      work for, nor your past experience, but I know for a fact that
      there are <b>lots</b> of companies that are actually very happy of
      the state of PHP still being maintained, compared to actually
      unmaintained tech that sometimes is younger than PHP. All these
      are different subjects.</p>
    <p>The point is: the PHPF needs funding, from anyone, because
      without it, PHP will die, and the millions of apps worldwide that
      use PHP will be at risk, and their users with it, which would
      cause a lot of unimaginable problems.</p>
    <p><br>
    </p>
    &gt; You first need to have a working, proven track record of
    leadership capable
    <br>
    &gt; of merging new features into PHP. 
    <p>What you call a "leadership capable of merging new features into
      PHP" is the actual work of the core maintainers, the PHP release
      managers, and the volunteering community that accepts to read the
      internals, RFCs, PRs, etc.<br>
      This is the <b>current way</b> of doing things, and I don't
      understand why you make this comment about "You first need to
      (...)" while it's already the case right now, and has been for
      many years now.</p>
    <p><br>
      &gt; Internals currently has exactly the opposite track record:
      this has to
      <br>
      &gt; change in order for both PHP and the PHPF to succeed.
      <br>
    </p>
    <p>Opposite to what? Merging new features to PHP? If you go to the <a
        moz-do-not-send="true"
        href="https://www.php.net/manual/en/appendices.php">PHP:
        Appendices</a> page on php.net, there are a lot of "Migrating
      from (...)" pages that contain all the new features merged in PHP
      in each minor and major versions. Reading them for <b>any</b> version
      shows that there are a <b>lot</b> of new features on all new PHP
      versions, and actually way more than what is presented in the <i>"What's
        new in PHP X.Y?"</i> blog posts that we see popping out on the
      web every year.<br>
      Your comment is just false, internals <b>do</b> have a track
      record of working successfully in adding new features to PHP.</p>
  </body>
</html>

--------------SuajdzusSFB8O8lc79M5Me3W--