Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130322
Precedence: list
MIME-Version: 1.0
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com> <CAPyj-LAajGgbhtibKGpWkM6TpHM2mNW68h=pUW81bC+-PaGzpg@mail.gmail.com>
In-Reply-To: <CAPyj-LAajGgbhtibKGpWkM6TpHM2mNW68h=pUW81bC+-PaGzpg@mail.gmail.com>
Date: Sun, 15 Mar 2026 11:17:57 +0200
Message-ID: <CAMW7n8A1hL40ke7Y2FRiOP-Z2watKCHFxhUbL0hwMQ8LbB60kg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] php-community: a faster-moving, community-driven PHP.
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

Hello!

> However, this proposal would put a completely unrealistic burden on php-s=
rc maintainers.

It seems to me this is an organizational problem that certainly has a
good solution.
In my company we also use something similar.
In practice it does not require that much effort. Moreover, right now
I am doing essentially the same thing for the TrueAsync project:

- the php-src code is updated
- tests are run
- if the tests pass, the code proceeds further

I am doing this manually, although the process could be automated.
TrueAsync currently has about 18,000+ lines of changes in PHP-SRC.
Over these six months my personal attention was required only 2=E2=80=933
times. I can confirm a similar experience with other projects as well.
A large number of different solutions can be devised here, both at the
level of flow and rules, and at the level of technical approaches. So
yes, it is a problem.
But it is a problem that has a solution.

> There's no real veto for php-src maintainers,
This question is more complex. I personally prefer the models used by
Go and Python, which rely on consensus rather than voting. I would
only add a long path of iterative development, where a feature reaches
users at an early stage. Releasing a feature early is what provides
quality guarantees, something that is well confirmed by modern IT
practice.
Building a quality product using the scheme =E2=80=9Cfirst we design an RFC
here =E2=86=92 then nobody can actually implement it=E2=80=9D has historica=
lly not
worked well. Companies spent millions of dollars on this approach in
the 1960s=E2=80=9370s, and the percentage of successful projects built this
way was extremely small.

This applies not only to the async project. Generics and most
moderately complex features are in the same boat.

> I honestly think this would be catastrophic.
Not impossible. Although using statistics and real-world usage to
evaluate features is definitely useful. The question is how to use it
most effectively.
I think this requires some thought.

Best regards, Ed